如何用Service Worker响应策略实现页面秒开优化

Service Worker 想让页面秒开，核心思路很简单：不必等待网络返回最新数据，而是先将缓存内容呈现给用户，后台再悄悄更新。这种“先给旧版，再换新版”的机制，正是 Stale-While-Revalidate 策略的精髓。下面拆解具体落地步骤。

拦截 fetch 请求并启用缓存优先逻辑

Service Worker 的 fetch 事件是实现秒开的关键。如果未在第一时间调用 event.respondWith()，浏览器会默认发起网络请求，导致缓存策略失效。对于首页这类关键导航请求，需要单独识别并执行缓存逻辑：

• 使用 new URL(event.request.url) 判断请求类型——例如通过 request.destination === 'document' 或匹配路径 / 来锁定页面导航。
• 调用 caches.match(event.request) 尝试从缓存中获取响应。
• 缓存命中后，立即返回给浏览器；同时用 fetch(event.request) 发起后台请求，获取最新资源。
• 收到新响应后，注意使用 response.clone() 分别用于浏览器和写入缓存——否则流一旦被消费便无法复用。

通过这种方式，用户看到的始终是缓存中的页面，几乎瞬间呈现；而后台更新由 Service Worker 默默完成，下次访问时缓存已是最新版本。

预缓存首屏必需资源（Install 阶段）

首次访问时缓存为空，秒开无从谈起。因此需要在 install 事件中将首页骨架、关键 CSS、JS、Logo 等静态资源提前存入缓存。具体操作：

• 调用 caches.open('v1-static') 创建专属缓存空间（建议名称包含版本号，便于后续管理）。
• 使用 cache.addAll([...urls]) 批量预存——URL 必须使用绝对路径或相对 Service Worker 脚本的路径。
• 配合 event.waitUntil() 确保安装完成前所有缓存操作执行完毕，否则安装会失败。
• 建议：install 阶段仅缓存静态资源，动态接口或 HTML 模板更适合运行时按需缓存。

启用导航预加载（Navigation Preload）

传统 Service Worker 启动存在延迟，尤其是冷启动时会阻塞首屏加载。导航预加载正是为解决此问题而生：让浏览器在 Service Worker 初始化的同时，并发请求页面资源，大幅压缩等待时间。实现方法：

• 注册时调用 registration.navigationPreload.enable()。
• 在 fetch 事件中优先检查 event.preloadResponse，若预加载响应存在，直接返回。
• 若无预加载响应，再回退到 Stale-While-Revalidate 流程。
• 兼容性方面，Chrome、Edge、Firefox 均已稳定支持，iOS Safari 从 11.3 开始加入，可放心使用。

合理管理缓存生命周期与版本

缓存清理需要技巧——不清理会导致旧资源长期残留，影响功能更新；清理过猛又会破坏秒开体验。最佳清理时机是 activate 阶段：

• 在 activate 事件中遍历 caches.keys()，将非当前版本名的缓存（如旧版 v0-static）逐个删除。
• 使用 cache.delete() 逐条清理，避免一次性全清空，影响正在使用的资源。
• 注意不要在 Service Worker 的全局作用域中维护状态变量（如计数器、标志位），因为进程休眠后变量会被重置，无法可靠使用。
• 缓存键建议带上版本号，例如 'pages-v2'，便于灰度发布和回滚——升级时只需修改版本号，旧缓存自动清理，新缓存无缝衔接。

综上所述，Service Worker 秒开优化的核心组合拳是“先用缓存顶上、后台静默更新、版本管理跟上”。按上述步骤落地，首屏加载速度通常可控制在 1 秒以内，用户体验将实现质的提升。