你以为 ServiceWorker 加了就快了？今天 Chrome 把这件事彻底变了

每次用 SPA 点一个链接，浏览器其实要分两步走：先把导航请求发出去，然后等 ServiceWorker 里的 fetch 处理器决定怎么响应。但这里有个隐藏的坑——如果你的 ServiceWorker 还没在跑，浏览器得先把它启动起来，才能执行 fetch 事件。这段启动时间，几十到几百毫秒，全都得让用户等着。

这个延迟不是你的代码有问题，是浏览器处理 ServiceWorker 的机制决定的——网络请求必须等 SW 启动完成后才能被 fetch 处理器拦截。写 PWA 的人都知道 ServiceWorker 能离线、能缓存，但很少有人意识到，它的冷启动本身就成了一道性能门槛。

Chrome 154 稳定版今天用 ServiceWorkerAutoPreload 把这件事彻底原生化了。

ServiceWorkerAutoPreload 是怎么工作的？

这个功能的核心思路很简单：让网络请求和 ServiceWorker 启动并行跑，而不是串行等。

没有这个功能的时候，浏览器会先启动 ServiceWorker，等它完全就绪后再发导航请求。ServiceWorkerAutoPreload 模式下，浏览器在启动 SW 的同时就把导航请求发出去了——两条线同时跑。如果你的 fetch 处理器直接返回缓存内容，浏览器就直接用缓存那条线的结果，preload 发出的请求被丢弃；如果 fetch 处理器决定走网络，preload 发出的请求可以被复用，节省了这段时间。

这不是一项全新的 API，而是浏览器内部的行为优化，不需要你改一行代码。但它也尊重已有的导航预加载机制——如果你已经接入了 Workbox 的导航预加载，两套机制不会冲突，AutoPreload 会在已有配置的基础上静默生效。

从 Chrome 140 到 154，这功能走完了整个发布周期

ServiceWorkerAutoPreload 最早是 Chrome 140 在 Android 和桌面端同时引入的，最初是企业策略控制（ServiceWorkerAutoPreloadEnabled），作为临时方案让企业 IT 管理员决定要不要开。后来 Chrome 移除了这个企业策略，改为默认启用。

Chrome 154 则是它进入稳定版后第一次完整覆盖所有平台——Windows、Mac、Linux、ChromeOS、Android 全员支持。这意味着从现在起，全球用户在访问你的 PWA 时，只要他的 Chrome 版本够新，就会自动享受这个优化。

对你的 PWA 意味着什么？

如果你的 ServiceWorker 逻辑很轻——只有几行缓存策略——启动延迟可能只有几十毫秒，感受不明显。但如果你的 SW 里接了 Workbox、接了 Google Analytics、接了消息推送初始化，这段启动时间可能会拖到几百毫秒，TTFB 直接受直接影响。

Chrome 团队在 Intent to Ship 邮件里明确说了这个问题的严重程度：最坏情况下，ServiceWorker 本身的启动加上 fetch 处理器执行，可以占用数百毫秒的导航关键路径。而这段延迟，用户感知到的就是点击链接之后那一小段白屏或卡顿。

ServiceWorkerAutoPreload 把这段延迟从串行变成了并行，本质上是用一条额外的网络请求换来的。服务器端会多处理一些请求——因为在某些情况下 SW 会 fallback 到网络，这时 preload 发出的那条请求会被用到，不算浪费。

怎么验证它有没有生效？

Chrome DevTools 的 Network 面板里，如果一个导航请求命中了 AutoPreload，会在 Timing 页签里看到一个新的阶段说明。你也可以观察同一 URL 连续访问的 TTFB 差异——ServiceWorker 冷启动之后的第二次访问，SW 已经在内存里了，走正常 fetch 拦截路径；第一次访问则触发了 AutoPreload，两者对比就能看出效果。

一个容易忽略的盲区

很多团队在优化 PWA 性能的时候，会花大量时间调缓存策略、调 Workbox 配置、调资源预加载，但 ServiceWorker 的启动时间本身很少被当回事。这个延迟不是”网络慢”，不是”代码写得烂”，是浏览器和 SW 协作机制决定的，用更好的代码没法绕过去。

ServiceWorkerAutoPreload 等于把这件事从”你得忍着”变成了”浏览器自己修了”。Chrome 154 之后，全球 94% 以上的 Chrome 用户访问你的 PWA 时，冷启动的等待时间会自动缩短。

下一步：如果你维护的 PWA 有明显的首次导航延迟，打开 DevTools 看一次冷启动的 Network Timing，把 TTFB 记录下来。升级到 Chrome 154 之后重跑一次，这个数字应该会有可观的下降。