Performance API 是性能“显微镜”，需结合FP、FCP、LCP、CLS等核心指标，利用Resource Timing、Layout Shift、Paint等API精准定位渲染瓶颈，并通过帧耗时监控与优化前后对比验证实效。
Performance API 不是“加速器”，而是“显微镜”——它本身不提升性能，但能精准暴露渲染链路中真正拖慢用户感知的环节。关键在于用对指标、拆解阶段、针对性干预。
盯住核心渲染指标，别被平均值骗了
FP（首次绘制）、FCP（首次内容绘制）、LCP（最大内容渲染）和 CLS（累积布局偏移）是反映用户视觉体验的硬指标。但只看数值没用，得结合 timing 数据定位“为什么慢”：
-
FCP 高但 LCP 更高？说明首屏有内容，但关键模块（如商品主图、标题）加载或渲染被阻塞，需查
performance.getEntriesByType('resource')中对应图片/字体的duration和transferSize； -
LCP 元素触发重绘？用
performance.getEntriesByType('paint')对比动画开始前后的 FP/FCP/LCP 时间戳，若 LCP 明显后移，大概率是 CSS 动画触发了非合成属性变更（如width、top），应改用transform和opacity； -
CLS 突然升高？不是等用户反馈才查，可在页面加载后立即调用
performance.getEntriesByType('layout-shift')捕获偏移事件，定位未设宽高的图片、异步插入的广告位或字体加载导致的回流。
用 Resource Timing 锁定资源瓶颈
渲染卡顿常源于某个资源拉得太久，而非 JS 执行慢。重点看三类资源的耗时分布：
-
CSS 文件：检查
responseEnd - fetchStart是否 > 200ms，若高，说明 CDN 缓存未命中或未启用 Brotli 压缩； -
关键图片：对比
decodedBodySize和transferSize，若比值远大于 1，说明压缩率低或格式老旧（优先用 WebP/AVIF）； -
字体文件：若
domainLookupStart到connectStart耗时长，说明字体域名未预连接，应在<head>加<link rel="preconnect" href="https://fonts.googleapis.com">。
主动测量帧耗时，而不是等卡顿发生
动画或滚动卡顿往往在低端机上才暴露，靠肉眼判断太滞后。用 PerformanceObserver + requestAnimationFrame 实时捕获：
- 监听
paint类型条目，确认 FCP 是否被第三方脚本延迟； - 在 rAF 回调中记录起止时间，单帧 > 16.7ms 即标记为潜在卡顿；
- 上报时附带
navigator.hardwareConcurrency和devicePixelRatio，区分是 JS 任务过重（多核设备也卡）还是渲染管线压力大（仅双核设备卡）。
验证优化是否真实生效
改完代码不能只看“平均 FPS 60”，要查稳定性：
- 导出 Performance 面板录制数据，分析帧时间标准差 —— > 3ms 就说明节奏抖动；
- 对比优化前后
performance.getEntriesByType('navigation')[0].largestContentfulPaint的startTime，下降幅度是否匹配预期； - 对 LCP 元素添加自定义 mark：
performance.mark('lcp-element-ready')，再用performance.measure()计算从首屏触发到该元素就绪的全程耗时，排除干扰项。
