如何利用 Performance API 分析 Service Worker 缓存命中对性能的真实增益-js教程-PHP中文网

Performance API 通过匹配带 X-Cache-Hit 响应头的资源加载记录，对比缓存命中与未命中时的 duration 及网络阶段时间戳，量化验证缓存带来的真实性能提升，如 CSS 文件加载从 320ms 降至 3.2ms。

如何利用 performance api 分析 service worker 缓存命中对性能的真实增益

Performance API 本身不直接暴露 Service Worker 缓存命中状态，但它能精准捕获缓存生效后带来的**真实性能变化**——比如请求是否绕过网络、资源加载是否零延迟、首屏是否提前完成。关键在于把缓存行为和 Performance 时间戳对齐，用数据验证“缓存到底快了多少”。

Service Worker 的 fetch 事件中，可通过 event.request.destination 和 URL 特征识别关键资源（如 HTML、CSS、JS），再结合 performance.getEntriesByName() 匹配对应资源的加载记录：

在 SW 中为缓存返回的响应打标记，例如：response.headers.set('X-Cache-Hit', 'true')
前端 JS 监听 performance.getEntriesByType('navigation') 或 getEntriesByType('resource')，筛选出带 X-Cache-Hit: true 响应头的条目
对比同资源在未命中缓存时的 duration（网络耗时）与命中时的 duration（通常

缓存的价值在断网或高延迟场景最明显。可借助 Performance API 搭配模拟环境做对照测试：

用 Chrome DevTools 切换“Offline”或“Slow 3G”，触发 SW 返回预缓存资源
调用 performance.getEntriesByType('navigation') 获取 loadEventEnd - navigationStart，即整页加载耗时
对比同一页面在在线+无缓存、在线+缓存、离线+缓存三种状态下的该值，差值即为缓存带来的实际节省
重点关注 LCP（最大内容渲染时间）：若 LCP 资源来自缓存，其 renderTime 往往比网络加载早 200–800ms

缓存不仅影响加载，更决定应用何时真正可用。通过 Performance API 追踪关键交互节点：

在 SW 的 install 阶段缓存核心 JS 后，记录 performance.mark('sw-static-cache-ready')
主页面中，在关键模块初始化完成时打点：performance.mark('app-interactive')
用 performance.measure('tti-from-sw-ready', 'sw-static-cache-ready', 'app-interactive') 计算从缓存就绪到可交互的时间差
若该差值显著小于未启用 SW 的版本，说明缓存减少了 JS 解析/执行依赖网络的等待

performance.getEntriesByType('resource') 提供每个资源的详细阶段耗时，是判断缓存是否真正生效的黄金依据：

缓存命中的资源，transferSize 应为 0（无网络传输），encodedBodySize > 0（本地读取）
检查 connectStart === 0 && secureConnectionStart === 0，确认跳过了 DNS、TCP、TLS 环节
对比同一 CSS 文件两次访问：第一次 duration = 320ms（含网络），第二次 duration = 3.2ms（纯内存读取），增益达 99%

不复杂但容易忽略：Performance API 给的是结果数据，而 Service Worker 控制的是过程逻辑。把两者对齐，才能说清“缓存不是理论上快，而是这次真的快了 472ms”。