Performance API 优化渲染耗时需建立“测量—归因—干预—验证”闭环，聚焦 FCP/LCP 等用户感知指标，用 PerformanceObserver 捕获 paint 条目，结合 resource/navigation 数据归因瓶颈，监听 longtask 和帧耗时定位主线程卡顿，轻量采样上报并分析标准差验证效果。
用 Performance API 优化渲染耗时，核心不是堆指标，而是建立“测量—归因—干预—验证”的闭环。重点抓真实用户看到内容的时间（如 FCP、LCP），再顺藤摸瓜定位拖慢它的资源、脚本或布局行为。
捕获关键视觉节点，聚焦用户感知时刻
首屏是否“有东西出来”，不能看 DOM 加载完没完，要看浏览器真正画出内容的那一刻：
- 用 PerformanceObserver 监听
paint类型条目，拿到 FCP（首次内容绘制）和 LCP（最大内容绘制）时间戳，它们直接对应用户“页面动了”“主区块出来了”的感觉 - 对 SPA 路由跳转后的子页面，务必加
buffered: true，避免监听滞后导致错过首帧 - 别依赖已废弃的
performance.timing，预览或 WebView 环境中它常返回 0；改用performance.getEntriesByType('navigation')[0]获取稳定、语义清晰的各阶段耗时
关联阻塞资源，看清谁拖慢了首屏
知道 FCP 是 1200ms 没用，得知道这 1200ms 里哪 400ms 花在等一张图、哪 300ms 卡在 JS 执行上：
- 调用
performance.getEntriesByType('resource')，筛选出initiatorType === 'img'或'fetch'的资源，检查它们的duration和startTime - 若 LCP 是一张 hero 图，但该图的
duration高达 800ms，就要查是否没配srcset、没压缩、或 CDN 缓存未命中 - 若首屏数据接口 TTFB（
responseStart - requestStart）持续 >500ms，瓶颈就在服务端或网络链路，前端优化空间有限
定位主线程瓶颈，避免“看不见”的卡顿
很多渲染延迟不是资源慢，而是 JS 抢占了主线程，让浏览器没空画帧：
- 监听
longtask类型条目，识别执行超 50ms 的 JS 任务，尤其是路由切换、列表渲染、复杂计算等场景 - 动画场景下，用
requestAnimationFrame+performance.now()测单帧耗时，>16.7ms 就是潜在卡顿，连续多帧超标说明 JS 或布局操作过重 - 避开强制同步布局：不在 rAF 中读取
offsetTop、getBoundingClientRect()等会触发重排的属性；动画只用transform和opacity
轻量上报与持续验证，让优化可衡量
上线后不监控，等于没优化。但全量采集会反噬性能，需策略性取舍：
- 只对 FCP、LCP、自定义 patch-duration（如 React 更新耗时）做采样上报，比如 5% 用户
- 当某次 FCP > 2s 或单帧 > 100ms 时，触发全量采集并带上路由、设备型号、网络类型等上下文
- 用
navigator.sendBeacon()上报，确保页面卸载前数据不丢；上报体控制在 1KB 内，只传必要字段 - 验证优化效果时不只看平均值，要分析帧耗时标准差——抖动大，说明节奏不稳，用户感知依然差
