不能用 domcontentloaded 或 load 监控首屏真实耗时，因前者忽略 cssom 和绘制，后者等待全部资源加载，均无法反映用户实际“看到内容”的时间；fcp/lcp 才是真实指标，需 performanceobserver 在 head 内同步注册捕获。
为什么不能用 DOMContentLoaded 或 load 监控首屏真实耗时
这两个事件在现代页面中已严重偏离用户“看到内容”的实际时间点：DOMContentLoaded 只等同步脚本执行完和 DOM 构建完成，但此时 CSSOM 可能还没就绪、布局尚未触发；load 更糟，它强制等待所有图片、iframe、字体加载完毕，哪怕首屏文字早已渲染完成，也会被懒加载广告拖慢数秒。
真实瓶颈常发生在“DOM 就绪但白屏依旧”——说明关键 CSS 未下载、JS 阻塞样式计算、或浏览器还没走到 paint 阶段。这类场景下，DOMContentLoaded 提前触发反而会误导你“页面很快”，掩盖 CRP 中的 layout/paint 卡点。
- SPA 路由跳转后，
DOMContentLoaded不再触发，但 FCP/LCP 仍会更新，必须靠PerformanceObserver捕获 - SSR 页面中，HTML 已含首屏 DOM，但 hydration 前的 JS 执行可能延迟 paint，
load完全无法反映这个阶段 - 第三方资源（如 analytics.js）若没加
async，会直接阻塞 parser，但load时间里根本看不出它是罪魁祸首
PerformanceObserver 必须在
FCP 和 LCP 是一次性事件：浏览器在首次绘制发生时生成并立即派发，不会缓存、不重放、不等待 observer 注册。如果 observer 在 DOMContentLoaded 或 window.onload 里初始化，线上基本收不到数据——因为 paint 早已发生并丢弃。
正确做法是把初始化脚本内联在 最顶部，不加 defer、不加 async、不走构建产物打包流程（避免 chunk 加载延迟）：
<script>
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.name === 'first-contentful-paint') {
sendToMonitoring({ metric: 'FCP', value: entry.startTime });
}
}
});
observer.observe({ entryTypes: ['paint'] });
</script>
- 必须同时监听
['paint', 'navigation']：前者抓 FCP/LCP，后者提供 TTFB、重定向链等上下文，单监听paint会丢失网络层归因 - 不要在
setTimeout或模块顶层 await 后注册，哪怕只延迟 1ms，都可能错过 FCP - 若用 Webpack/Vite，该脚本需配置为
inject: 'body'以外的模式，确保它出现在 HTML 字节流最前端
CRP 全链路打点需要三类标记协同
performance.now() 只是高精度计时器，无法感知渲染流水线节奏。要覆盖“JS 触发 → 渲染准备完成 → 首帧绘制”全程，必须分段打点并用 performance.measure() 关联：
- 起始点：
performance.mark('crp_start')放在业务逻辑触发渲染前，比如点击回调开头、API 数据 resolve 后、requestAnimationFrame回调第一行 - 中间点：
performance.mark('crp_ready')放在 DOM 更新 + 样式应用后，可紧跟el.offsetHeight（强制 layout 检查）之后，但注意避免频繁读取触发布局的属性，否则引入额外开销 - 终点：靠
PerformanceObserver捕获first-contentful-paint，其startTime即为 CRP 终点 —— 注意字符串字面量是'first-contentful-paint'，不是变量名
之后调用 performance.measure('crp_total', 'crp_start', 'first-contentful-paint') 才能得到端到端耗时。漏掉任一环节，测量结果就只是某段 JS 执行时间，而非用户真正“看见”的延迟。
指标归因比采集更难：区分网络、渲染、框架层干扰
拿到 FCP 数值只是开始，真正难的是判断它卡在哪一层：
- TTFB 偏高？先看
navigation.timing.responseStart - navigation.timing.fetchStart，排除 DNS/连接干扰；再结合connectEnd - secureConnectionStart判断是否 TLS 握手慢（iOS WebKit 对 OCSP stapling 敏感） - FCP 和 LCP 差距大？说明首屏内容早出现，但最大元素（如 banner 图）加载慢，应检查该资源是否被 preload、是否启用了
fetchpriority="high" - CRP 耗时长但 DOM 构建快？大概率是关键 CSS 阻塞，用 Coverage 面板查 CSS 实际使用率，低于 30% 的规则应剥离或 media 条件加载
框架层（React/Vue）常掩盖真实瓶颈：hydration 时间被计入 JS 执行，但实际影响的是后续 paint；服务端模板渲染耗时会被混进 TTFB，需用 serverTiming header 单独上报。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
