写过前端的人都踩过这个坑——每次点一个链接，浏览器都要先等 Service Worker 启动，才肯发网络请求。今天 Chrome 154 把这件事彻底原生化了。

写过前端的人都踩过这个坑——每次点一个链接，浏览器都要先等 Service Worker 启动，才肯发网络请求。今天 Chrome 154 把这件事彻底原生化了。

Service Worker 的 fetch 处理能力让网页离线可用、缓存加速，但代价是每次导航都要多等一段冷启动时间——有时候甚至比直接请求还慢。Chrome 154 推出的 ServiceWorkerAutoPreload，就是来解决这个矛盾的：浏览器在启动 Service Worker 的同时就并行发出网络请求，两件事同时跑，最终在 fetch 事件里汇合。如果你的 fetch handler 最终用 respondWith() 返回了结果，那就消费这个预加载的响应；如果 fetch handler 返回了 fallback，浏览器就直接把预加载的响应喂给页面。整个过程不需要你改一行代码。

原理很直接：旧逻辑是串行的——必须等 Service Worker fully ready 才发网络请求；新逻辑是并行的——浏览器同时做两件事，最终合并。极端情况下 Service Worker 冷启动可能花几百毫秒，这个优化就能把这几百毫秒从用户等待时间里抠掉。

需要条件：Service Worker 没有在运行（冷启动场景），fetch handler 返回的结果和自动预加载的请求一致（否则预加载结果被忽略）。Chrome 团队通过判断这两个条件是否满足来决定是否触发优化，对开发者来说完全不透明。

Chrome 154 目前是 stepped rollout（逐步推送），企业管理员可以通过 ServiceWorkerAutoPreloadEnabled 策略临时控制开关。过了这个版本之后这个策略就会被移除，优化变成默认行为。对普通开发者来说，你现在什么都不用做——浏览器自己会判断什么时候该并行、什么时候不该。

如果你在用 Workbox 的 NavigationPreload，其实逻辑很接近：也是让浏览器和 SW 启动并行发请求，只是 NavigationPreload 需要你在注册时写 navigationPreload.enable()，还要在 fetch 里消费 event.preloadResponse。ServiceWorkerAutoPreload 是把这件事做成了浏览器默认优化，不需要任何代码介入。两者可以共存，互不干扰。

下一步：打开 Chrome 154，清一下 Service Worker，重新访问一个接了 SW 的站点，打开 DevTools Network 面板，看一下 ServiceWorkerAutoPreload 相关的 timing 信息。如果你的站点 fetch handler 大量使用 cache-first 或 NetworkFirst 策略，这个优化效果会最明显。