怎样在HTML5中使用NavigationPreload技术提升ServiceWorker启动性能

Navigation Preload 通过并行发起主文档请求消除 SW 冷启动首屏阻塞，需注册后显式启用 navigationPreload.enable()，fetch 中优先 await event.preloadResponse 并降级兜底。

Navigation Preload 不是“加快 Service Worker 启动”，而是让浏览器在 SW 启动过程中并行发起主文档请求，从而消除冷启动带来的首屏阻塞。关键在于它把原本串行的“SW 初始化 → 再发请求”变成“SW 初始化 + 请求同时进行”，真正压缩的是用户感知的等待时间。

注册时必须显式启用预加载

仅注册 Service Worker 不会自动开启 Navigation Preload。必须在注册成功后，检查并调用 navigationPreload.enable()：

• 确保注册路径正确，且 SW 文件可被访问（如 /sw.js）
• 需判断 registration.navigationPreload 是否存在（旧版浏览器不支持）
• 启用后可选设置自定义请求头，例如标记预加载流量：registration.navigationPreload.setHeaderValue('X-Preload', 'true')

fetch 事件中优先使用 preloadResponse

在 Service Worker 的 fetch 事件里，不能只依赖缓存或网络，而要主动等待预加载结果：

• 用 event.preloadResponse 获取预加载的 Response 对象（它是一个 Promise）
• 如果该 Promise 成功解析出响应，直接返回它——这是最快速的路径
• 若预加载失败或未触发（如用户刷新太快、网络中断），再回落到缓存策略（如 Stale-While-Revalidate）或网络请求
• 注意：不要在 event.respondWith() 外部提前 resolve 或忽略该 Promise，否则会触发“preload cancelled”错误

配合作用域与缓存策略协同生效

Navigation Preload 只对导航请求（request.destination === 'document'）有效，因此需明确区分资源类型：

立即学习“前端免费学习笔记（深入）”；

• HTML 文档走预加载 + 网络兜底（保证结构最新）
• CSS/JS/图片等静态资源仍走常规缓存策略（如 Cache-First）
• 确保 SW 作用域覆盖所有需要控制的页面（如注册时指定 { scope: '/' }），否则部分页面无法触发预加载
• 避免在 install 阶段缓存大量 HTML，因为预加载本质是绕过缓存取网络最新版

兼容性与降级处理很关键

该功能已在 Chrome、Edge、Firefox 和 iOS Safari 11.3+ 中稳定支持，但仍需考虑降级：

• 注册时检测 navigator.serviceWorker?.ready 和 navigationPreload 能力，无则跳过启用逻辑
• fetch 事件中始终保留 fallback：即使 event.preloadResponse 为 undefined 或 reject，也要有兜底响应
• 搭配 skipWaiting() 和 clients.claim()，确保新版 SW 能及时接管，避免用户长期停留在旧版逻辑中