配了三年 PWA，每次导航请求都要被 SW 启动时间卡住——Chrome 154 把这件事自动并行化了

每次用 PWA 导航，用户都在等一个看不见的延迟。

Service Worker 的 fetch handler 是为了让页面跑得更快而生的——但当它还没启动的时候，情况正好反过来：浏览器必须先等 Service Worker 完全启动，才敢发网络请求。这个启动时间，在桌面端约 50ms，在移动端约 250ms，在低端机或 CPU 紧张时可以达到 500ms 以上。也就是说：你写 SW 是为了提速，但它反而让第一次导航比不用 SW 还慢。

Chrome 154 稳定版把这件事彻底修了——ServiceWorkerAutoPreload 自动让网络请求和 SW 启动并行跑，不需要改一行代码。

SW 启动延迟：被低估的 PWA 性能杀手

Service Worker 参与全球约 15% 的页面加载。这个 API 提供了离线缓存、后台同步、推送通知等能力，但它的 fetch handler 是在导航请求的关键路径上被调用的。如果 SW 还没启动，浏览器必须先把 SW 拉起来——这个过程没有任何缓存可言，每次冷启动都要重来。

传统解法是 NavigationPreload API：开发者手动调用 navigationPreload.enable()，然后在 fetch handler 里读 event.preloadResponse。这个 API 从 2017 年就存在了，Chrome 59+、Firefox 99+、Safari 15.4+ 都支持，但实际用的人很少——毕竟每次写 SW 都要多写一坨代码。

Chrome 团队认为这事应该浏览器自己搞定，不需要开发者操心。

ServiceWorkerAutoPreload：浏览器自动并行，零代码

Chrome 会自动决定什么时候适用这个优化。判断标准包括：

• fetch handler 返回 fallback（走网络）的比例高不高
• SW 启动时间和 fetch handler 执行时间是否真的在拖累页面加载
• SW 是否处于未启动状态

符合条件时，Chrome 在 SW 启动的同时就发出一路网络请求。如果 SW fetch handler 里调用了 fetch(event.request)，浏览器直接拿这个已经在跑的网络请求的结果作为响应——不会发起第二次请求。如果 fetch handler 没有调用 respondWith() 直接走了 fallback，浏览器直接用之前并行发出的那个网络请求的响应，不需要重新发。

整个过程对开发者完全透明，不需要任何代码修改。

和 NavigationPreload 什么关系

NavigationPreload 是手动开启的 opt-in 优化，两者不会冲突。如果你的 SW 已经在用 Service-Worker-Navigation-Preload 头，Chrome 会尊重这个行为，不会叠加额外的 auto-preload。

如果你想主动退出 ServiceWorkerAutoPreload，可以注册 Static Routing API 规则，把所有请求都路由到 fetch handler：

self.addEventListener(install, e => {
  e.addRoutes({
    condition: { urlPattern: new URLPattern({}) },
    source: "fetch-event"
  });
});

这样告诉 Chrome：别替我自动优化，我自己管。这种写法同时也是 ServiceWorkerAutoPreload 的 opt-out 信号。

当前状态

ServiceWorkerAutoPreload 目前在 Chrome 140 中以开发者试用（Behind a flag）形式运行，Chrome 154 Beta（2026 年 9 月 2–24 日）已经包含该功能，稳定版预计 2026 年 9 月 9 日向所有用户推送。Firefox 和 Safari 尚未表态支持。

需要注意：Chrome 可能会取消 auto-preload 请求以节省资源——如果 fetch handler 迅速返回了缓存响应，auto-preload 请求还没跑完就被中断了，这对服务器来说是可观测到的额外请求。

开发者该怎么做

大多数情况下：什么都不用做。这是纯浏览器内部的优化。

如果想验证它是否生效，可以打开 Chrome 的 Network Internals 面板（chrome://net-export），观察导航请求是否在 SW 启动前就已经发出。

几个依然有价值的做法：

• 保持 SW 启动时间 < 50ms：这是上限，auto-preload 只是不让你因为 SW 启动吃亏，但 SW 本身还是要尽量轻量化
• 非 Chrome 浏览器暂时没有这个优化：Firefox/Safari 用户仍受 SW 启动延迟影响，要不要继续用 NavigationPreload 手动优化，由你决定
• 已用 NavigationPreload 的不需要改：Chrome 会自动识别并尊重你的配置，不会 double-optimize

ServiceWorkerAutoPreload 是 Chrome 把「本来就应该浏览器做的事」补上了。配了三年 PWA 的开发者终于不用为这个看不见的坑再写一行 workaround 了。

—

• Chrome 154 稳定版预计 2026 年 9 月 9 日推送，关注 Chrome Releases 博客获取最新消息。*