关键是要在<head>内联脚本中用PerformanceObserver监听first-contentful-paint，结合Resource Timing定位阻塞资源，并用longtask捕获主线程卡顿，通过FCP/LCP交叉验证优化效果。
要发现并优化渲染瓶颈，关键不是等页面跑起来再看，而是从加载初期就捕获真实绘制行为，并把时间点和主线程活动关联起来。PaintTiming 和 PerformanceObserver 是最直接的抓手，配合 Resource Timing 和 longtask 监听，能准确定位“为什么用户看到内容慢”。
用 PaintTiming 精确捕获首次有效渲染（FCP）
FCP 是用户感知“内容出现”的第一个信号，单位是毫秒，起点为 navigationStart。它不等于 DOM 加载完成，也不依赖图片是否加载完，只要浏览器画出第一个文本、图标或非空白 SVG 就触发。
- 必须在 <head> 内联脚本中注册 PerformanceObserver，监听
first-contentful-paint类型，避免因延迟执行而漏掉条目； - 不要用
window.addEventListener('load')或DOMContentLoaded来读取，这些事件发生时 Paint 条目可能已被清理； - 示例代码应放在 HTML 最开头：
<script>
if ('PerformanceObserver' in window) {
new PerformanceObserver(l => {
l.getEntries().forEach(e => e.name === 'first-contentful-paint' && console.log('FCP:', e.startTime));
}).observe({ entryTypes: ['first-contentful-paint'] });
}
</script>
结合 Resource Timing 找出拖慢 FCP 的资源
FCP 被推迟，往往不是因为 JS 写得慢，而是某个 CSS、字体或关键 JS 还没下载完或解析完。Resource Timing 能暴露每个资源的真实耗时和传输细节。
- 调用
performance.getEntriesByType('resource')，筛选出initiatorType为link（CSS）、script或font的条目； - 重点关注
duration> 400ms 的字体（.woff2）或 CSS 文件，它们常阻塞渲染； - 检查
transferSize是否远大于decodedBodySize，若差异大，说明压缩未生效或 CDN 未开启 Brotli； - 对
name指向第三方域名的资源，对比connectStart与secureConnectionStart差值，超 150ms 表明 TLS 握手慢，需加<link rel="preconnect">。
用 PerformanceObserver 捕获长任务，定位主线程卡顿
用户觉得“卡”，常常不是加载慢，而是某段 JS 占用主线程太久，导致绘制被推迟。这类问题不会报错，也难靠肉眼识别，必须靠 longtask 类型监听。
立即学习“前端免费学习笔记（深入）”；
- 注册 observer 时明确指定
entryTypes: ['longtask', 'largest-contentful-paint']，一次拿到卡顿与首屏大图数据； - 单个任务
duration> 50ms 就构成风险，> 100ms 很可能已影响 FCP； - 常见诱因包括：未节流的
resize监听器、React 大量同步更新、复杂 CSS 选择器引发样式重计算； - 验证方式：在 Chrome DevTools Performance 面板录制，打开 “Main” 线程轨道，找红色长条——那就是阻塞绘制的长任务。
交叉验证与优化闭环
单独看 FCP 容易误判。比如 FCP 提前了，但 LCP 却更晚，说明首屏文字出来了，但主图或 banner 还卡着——这指向资源加载策略问题而非 JS 执行。
- 每次只改一项：比如只加
<link rel="preload" as="image">加载 banner 图，再测 FCP/LCP 变化； - 内联首屏 CSS，移除非关键 JS 的同步执行，这两项通常让 FCP 缩短 300ms 以上；
- 对关键图片启用
loading="eager"，对字体设置font-display: swap，避免白屏等待； - 所有优化后，用 WebPageTest 在 3G 模拟环境下多测三次，取中位数，排除网络抖动干扰。
