paint timing api 是浏览器原生性能接口,精准捕获 fcp 和 lcp 等首屏渲染时间点;需用 performanceobserver 在 内联脚本中监听 'first-contentful-paint' 和 'largest-contentful-paint' 事件,避免使用 load 或 domcontentloaded。

用 PerformanceObserver 监听关键渲染事件
在页面加载早期(建议放在 中的内联脚本里)注册监听器,确保不遗漏首屏指标:
- 监听
'first-contentful-paint'获取 FCP 时间 - 监听
'largest-contentful-paint'获取 LCP 时间 - 避免使用
load或DOMContentLoaded替代,它们与视觉呈现无直接关系
示例代码:
if ('PerformanceObserver' in window) {
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log(`${entry.name}: ${entry.startTime}ms`);
// 可上报至监控系统,如 entry.name === 'largest-contentful-paint'
}
});
observer.observe({ entryTypes: ['first-contentful-paint', 'largest-contentful-paint'] });
}
对比不同优化策略的实操要点
每次只变更一项策略,保持其他条件一致(同设备、同网络模拟、同缓存状态),才能归因准确:
- 压缩资源前后:用 Terser 压缩 JS 后,对比 FCP 是否提前 200ms+;注意观察 LCP 是否同步改善(说明关键路径 JS 执行更快)
-
图片格式升级:将 PNG/JPG 换成 WebP 并配合
loading="lazy",重点看 LCP 是否下降——因为主图往往是 LCP 元素 -
预加载关键资源:对 LCP 元素(如 banner 图)加
<link rel="preload" as="image" href="...">,FCP 可能不变,但 LCP 通常明显缩短 -
移除阻塞渲染的 JS:把非首屏逻辑延迟到
DOMContentLoaded后执行,FCP 和 LCP 都应提升,且 CLS(布局偏移)也会降低
结合 DevTools 验证与定位瓶颈
Paint Timing 数据需配合 Chrome DevTools 的 Performance 面板交叉分析:
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML,替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度,HTML 能同时承载排版、表格、SVG 等。
- 录制加载过程,打开“Rendering”帧率图层,查看首屏区域是否有长任务阻塞绘制
- 在“Main”线程中定位耗时过长的 JS 执行或样式重计算,这些会推迟 FCP/LCP
- 检查“Timings”下的 Paint 条目,确认首次绘制是否发生在 DOM 构建完成后、CSSOM 就绪之后
若 FCP 很低但 LCP 很高,大概率是 LCP 元素(如大图、视频)未被优先加载或解码慢;若两者都高,则问题更可能出在 HTML 解析、CSS 阻塞或服务端响应(TTFB >600ms)。
构建轻量级对比看板(可选)
无需复杂平台,用 localStorage + 简单统计即可做 A/B 对比:
- 为每种策略打标签(如
strategy:webp-lcp-preload) - 每次触发 LCP 时,存入本地:
localStorage.setItem('lcp_' + tag, entry.startTime) - 手动切换策略刷新页面,再读取对比数值——适合快速验证小范围改动
注意清除缓存或使用隐身窗口测试,避免资源缓存干扰结果。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










