Navigation Preload 的核心作用是让浏览器在 Service Worker 启动前并行发起主文档请求，消除首次导航延迟；需显式调用 enable() 启用，fetch 事件中须用 event.respondWith() 和 event.waitUntil(event.preloadResponse) 正确消费。
Navigation Preload 的核心作用，就是让浏览器在 Service Worker 还没完全启动时，就提前发起主文档请求。这样能绕过 SW 冷启动的等待空窗，把“等 SW 启动”和“发网络请求”这两个动作并行执行，从而消除首次导航的延迟。
注册时必须显式启用预加载
仅注册 Service Worker 不会自动开启 Navigation Preload。必须在注册成功后，主动调用 navigationPreload.enable()：
- 检查
registration.navigationPreload是否可用（现代浏览器基本都支持） - 调用
.enable()，它返回一个 Promise，可链式处理或忽略 - 若需定制请求头（例如透传认证信息），可在 enable 后调用
setHeaderValue('X-From-Preload', 'true')
fetch 事件中正确消费 preloadResponse
预加载响应不会自动生效，必须在 fetch 事件里显式使用 event.preloadResponse，且必须用 event.waitUntil() 保证其完成：
- 对导航请求（
request.destination === 'document'）优先判断event.preloadResponse - 用
event.respondWith()包裹整个响应逻辑，并在内部用event.waitUntil(event.preloadResponse)显式延长生命周期 - 避免直接
return event.preloadResponse，应包裹在respondWith中并处理 Promise 拒绝情况
配合缓存策略形成完整首屏链路
Navigation Preload 解决的是“第一次有网但 SW 没缓存时”的延迟，但它不是孤立方案：
- 搭配
StaleWhileRevalidate：预加载响应返回后，立即再发一次 fetch 更新缓存，下一次访问就能命中缓存 - 预缓存关键资源：在 install 阶段缓存首页 HTML 模板、骨架 CSS/JS，让 preload 响应+缓存内容共同支撑秒开
- 避免误用：非导航请求（如图片、API）不走 preload，也不应在 fetch 中无差别 await preloadResponse
注意兼容性与常见陷阱
该功能已在 Chrome、Edge、Firefox 和 Safari 11.3+ 稳定支持，但仍有细节需留意：
- iOS Safari 对 preloadResponse 的 Promise 拒绝处理较敏感，建议 always catch 并 fallback 到 fetch
- 若页面重定向频繁，预加载可能被取消，此时
preloadResponse会 resolve 为 undefined - 服务器不能对预加载请求返回 304；若需协商缓存，应确保 ETag 或 Last-Modified 正确且服务端支持
