Performance API本身不优化资源加载，但能精准暴露瓶颈：通过Resource Timing拆解duration、TTFB、decodedBodySize等指标定位慢资源；结合preconnect、preload与强缓存策略主动加速关键资源；并借助P95、标准差及异常样本分析验证优化效果。
Performance API 本身不直接优化资源加载，但它能精准暴露瓶颈所在——关键在于把每类资源的加载行为拆解成可读、可比、可干预的时间节点，再结合浏览器机制做针对性改进。
定位慢资源：用 Resource Timing 筛出真问题
调用 performance.getEntriesByType('resource') 获取所有资源记录，重点关注三类指标：
- duration：总耗时。超过 2s 的资源需优先排查；
- responseStart - requestStart（TTFB）：首字节时间。若占比超 60%，说明服务端或 CDN 响应慢，不是带宽问题；
- decodedBodySize / transferSize：解码后大小与传输大小。两者差距大，说明压缩未生效；transferSize 持续偏高，提示未启用 Brotli 或图片未转 WebP。
特别注意 initiatorType：img、script、fetch 类资源常是首屏渲染的关键依赖，它们的延迟会直接拖慢 FCP 和 LCP。
加速关键资源：预连接 + 预加载 + 缓存协同
对核心业务强相关的资源（如订单 JS、首屏 CSS、主图），不能只靠 async 或 defer，要主动引导浏览器：
- 在
<head>中添加<link rel="preconnect" href="https://api.example.com">，提前完成 DNS、TCP、TLS 连接； - 对立即执行的脚本或阻塞渲染的 CSS，用
<link rel="preload" as="script" href="checkout.js">，避免 parser 发现晚、下载滞后； - 静态资源必须返回
Cache-Control: public, max-age=31536000，并配合内容哈希命名（如main.a1b2c3.js），实现长期强缓存。
识别加载毛刺：区分“慢”和“抖”
平均耗时正常但用户偶发卡顿？可能是 CDN 网络抖动。需抓取异常样本：
- 筛选
duration > 1000ms且TTFB / duration > 0.7的资源，大概率是 CDN 节点响应不稳； - 检查响应头中的
X-Cache或X-CDN-Node字段，对比同一资源在不同边缘节点（如sin01vstok03）的 TTFB 分布； - 若多个资源在同一次导航中集体 TTFB 延迟，需排查 DNS 解析（
domainLookupEnd - domainLookupStart）或 TCP 连接阶段是否异常拉长。
验证优化效果：不止看平均值
改完不能只看“平均加载快了 300ms”，要关注分布和稳定性：
- 统计 P95 duration，比均值更能反映用户最差体验；
- 对比优化前后 FCP/LCP 的标准差：若从 80ms 降到 25ms，说明帧节奏更稳；
- 上线后轻量监听
['resource', 'navigation']，仅上报超阈值条目（如duration > 3000），附带设备信息（hardwareConcurrency、devicePixelRatio），便于分层归因。
