你以为 SW 启动只能等？今天 Chrome 154 把这件事从根上变了

每次点一个链接，浏览器内部发生的事比你想的复杂得多。

如果有 ServiceWorker（SW），浏览器要经历这个顺序：先启动 SW → 等 fetch 事件触发 → SW 里判断走缓存还是网络 → 最后才真正发出请求。以前这个链条是串行的，SW 启动没完成，导航请求就只能干等着。

SW 启动一次要多久？WICG 官方提案里有数据：最多可达数百毫秒。对于要做首屏优化的站点来说，这段时间正好卡在关键路径上——你花了力气装了 SW，结果反而拖慢了导航。

Chrome 154 改变了这个顺序。ServiceWorkerAutoPreload 让导航请求和 SW 启动并行发出，不再等 SW 完全就绪再发请求。等 fetch 事件真正触发时，导航请求已经在路上了，响应回来直接进 handler 处理。

这和 NavigationPreload 有什么区别？NavigationPreload 是开发者手动在 SW 里调 event.preloadResponse = navigationPreload.register() 开启的，需要改代码。ServiceWorkerAutoPreload 完全自动，Chrome 自动判断哪些请求可以并行，不需要任何额外代码。

注意这个行为只对 GET 导航请求生效，子资源请求不走这个路径。

如果你的 SW 用了激进的预缓存策略——所有导航资源都提前存进了 CacheStorage——这个 API 对你影响不大，因为请求本来就会从缓存里瞬间返回，不会触发 SW 启动。

真正能受益的场景是 SW 没有完整预缓存、需要实时判断走缓存还是网络的场景。比如新闻站点、文档站这类无法预判用户下一步访问什么的地方，SW 每次都要重新 fetch 原始文档。

Chrome 154 正在逐步推出。想测一下你的 SW 启动时间？在 DevTools → Application → Service Workers 面板能看到 SW 上次启动耗时，也可以用 Performance.measure() 对比开/关 ServiceWorkerAutoPreload 的导航时间差。

一句话：以前 SW 启动是串行的，现在变并行了，不需要你写一行代码。