PerformanceObserver必须在最开头同步注册，否则FCP、LCP等关键指标将永久丢失；需内联脚本监听'paint'和'navigation'事件类型，且不可使用defer或async。
PerformanceObserver 必须在
FCP、LCP 这类指标一旦错过就永远收不到——页面渲染完成前没注册 observer，后续调用 performance.getEntriesByType('paint') 只会返回空数组。很多团队把监控脚本塞在 底部或等 DOMContentLoaded 后再执行，结果线上根本收不到首屏数据。
正确做法是：<script></script> 标签直接写在 内，不加 defer 或 async，且只做初始化和 observe() 调用：
<head>
<script>
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.name === 'largest-contentful-paint') {
sendToMonitoring({ metric: 'LCP', value: entry.startTime });
}
}
});
observer.observe({ entryTypes: ['paint', 'navigation'] });
</script>
</head>
- 必须同时订阅
'paint'和'navigation'：前者捕获 FCP/LCP，后者提供完整的加载上下文（比如重定向链、serverTiming） - 不要在
onload或setTimeout里调用observe()，此时 paint 事件早已触发并丢弃 - 若项目使用了模块化构建，需确保该脚本被标记为
type="module"且无 top-level await，否则仍可能延迟执行
Chrome DevTools Performance 面板默认配置会掩盖真实瓶颈
开全追踪项（比如 Memory、Screenshots、JS Heap）会导致录制数据膨胀、分析卡顿，反而让主线程长任务（>50ms）被淹没在杂乱的子任务堆栈里。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 只勾选
Rendering、Layout、Paint、Interactions—— 这四类足够定位卡顿帧与布局抖动 - 禁用
Memory和Screenshots，除非你明确要查内存泄漏或逐帧视觉异常 - 用
Ctrl+E（Windows）或Cmd+E（macOS）快捷启停录制，避免 Chrome 自身因录制过长而响应变慢 - 重点关注
Main轨道里连续超过 16ms 的长任务，右键 →Zoom to selection后看调用栈，而不是只盯着 FPS 数字
Lighthouse CI 中 render-blocking-resources 审计默认不启用
很多人以为 Lighthouse 默认会检查阻塞资源，其实它在 CI 模式下默认跳过这一项。不显式配置，就等于对内联 CSS、未加 async 的同步脚本完全失察。
立即学习“前端免费学习笔记（深入）”；
- 必须在
.lighthouserc.json中手动启用："audits": ["render-blocking-resources"] - 如果项目用了
<script type="module"></script>，但 CI 环境 Chrome 版本低于 61，Lighthouse 会误判为不支持，给出错误的“消除阻塞资源”建议 - 未指定
--preset=desktop或--preset=mobile，Lighthouse 就按默认模拟条件跑分，而该条件未必匹配你真实首屏 HTML 的加载上下文（比如是否启用了preload、preconnect） - 关键点：Lighthouse 报告里的 “Eliminate render-blocking resources” 建议不可直接照搬——
defer对内联脚本无效，async可能破坏依赖顺序
WebPageTest 的 Document Complete 和 fullyLoaded 差值大于 2s 就说明有问题
这个差值反映的是非阻塞资源（如埋点、日志上报、第三方 SDK）在后台持续拖慢整体完成感。很多人只扫一眼 Start Render 时间，却漏掉了更关键的中间态。
- 打开 Waterfall View，重点找红色标记的请求——特别是那些返回
204或超时的第三方 SDK，它们虽不阻塞渲染，但持续占用连接池 - 对比
First CPU Idle在 3G 模拟下是否稳定出现在DOMContentLoaded之后 500ms 内；如果不是，说明 JS 执行量已超出低端机承受阈值 - 别只看首屏时间，点开 Video 标签页看实际渲染过程——有些页面“快”是靠骨架屏作弊，内容实际加载延迟仍很高
- 若
Document Complete和fullyLoaded差值长期 >2s，应排查是否在load事件后仍发起大量非关键请求
async 属性、加了段内联 CSS）都能对应到某一个可解释的性能波动。这要求监控链路里 HTML 解析阶段的指标不可缺失，也不能被上层框架生命周期钩子覆盖掉。 
