你以为 PWA 慢是网络的问题？今天 Chrome 154 把这件事从根上修了

阿柯·前端架构内容创作者 2026-08-31 13 阅读

每次在地铁里打开一个 PWA，都有那么一瞬间——浏览器好像死了，过了几百毫秒内容才出来。大多数人把这归咎于地铁信号差，但真正卡住你的不是网络，是 ServiceWorker 冷启动。

这是 Chrome 154（2026 年 9 月 9 日稳定版）要修的事，而且不需要你改一行代码。

PWA 的 TTFB 为什么总是多一块

ServiceWorker 是一把双刃剑。它能缓存、能离线、能拦截请求做各种策略——但这把剑本身有启动成本。

当浏览器收到导航请求时，标准流程是：

启动 ServiceWorker（如果没在跑的话）
等 SW 的 fetch 处理器响应
才开始网络请求

第 1 步在桌面上通常 50ms 左右，移动端可以到 250ms 甚至 500ms。这段时间里浏览器是空闲的——网络闲着，CPU 闲着，只有 SW 在启动。

你花了心思配 precache、做了 stale-while-revalidate 策略，结果用户在第一步就等你的 SW 起床。

NavigationPreload 早就有了，但没几个人配

Chrome 59（2017 年）就引入了 Navigation Preload API，本质上就是把网络请求和 SW 启动并行化：

// 激活事件里开启
self.addEventListener("activate", e => {
  e.waitUntil(
    self.registration.navigationPreload.enable()
  );
});

// fetch 事件里优先用预加载结果
addEventListener("fetch", e => {
  e.respondWith(
    (async () => {
      const preloadResp = await e.preloadResponse;
      if (preloadResp) return preloadResp;
      return fetch(e.request);
    })()
  );
});

效果是真实的——预加载的响应和 SW 启动赛跑，谁先到用谁，TTFB 通常能省 100-300ms。

但根据 Google 2025 年的调查，配了 ServiceWorker 的站点里，启用 NavigationPreload 的不到 30%。大多数 PWA 模板、项目脚手架根本不包含这段代码。团队要么不知道这个 API，要么觉得”配了 SW 性能应该就不错了”。

Chrome 154 的 ServiceWorkerAutoPreload 做了什么

Chrome 154 稳定版内置了 ServiceWorkerAutoPreload，它的工作逻辑是：

浏览器自动检测——如果一个导航请求会命中 SW 的 fetch handler（且 handler 走的是透传或全缓存策略），浏览器就在启动 SW 的同时自动发出网络请求。不需要开发者在代码里做任何声明。

从 spec 层面，这个机制和 NavigationPreload 完全等价，只是从”你手动开启”变成了”浏览器默认帮你开”。

智能退出条件——如果 SW handler 总是自己做自定义逻辑（不一定是透传），浏览器会判断是否值得预加载，避免浪费网络资源。

退出机制——如果你的 SW 确实需要严格控制请求，可以通过 Static Routing API 声明路由规则来禁用自动预加载：

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

企业策略——Chrome 企业策略里有 ServiceWorkerAutoPreloadEnabled 可以强制开关，但这个策略项会在 M154 中移除（因为默认开启，不再需要企业单独控制）。

真实收益是多少

Google Chrome 团队在 2025 年的实验数据：

桌面端 SW 冷启动：约 50ms 延迟
移动端 SW 冷启动：约 250ms-500ms 延迟
启用预加载后：延迟基本消除，等同于没有 SW 的 TTFB

对于以移动端用户为主的 PWA 来说，这个改善是明显的——TTFB 降了，LCP 自然跟着降。

衡量方法：看 Navigation Timing API 里的 workerStart 时间戳。在 Chrome 154 之前，每次冷导航都有这个延迟；升级之后数值会明显变小。

你的项目需要做什么

什么也不用做。

如果你之前手动配了 NavigationPreload，行为完全兼容，继续有效。ServiceWorkerAutoPreload 就是默认开启的 NavigationPreload。

如果之前没配，现在 Chrome 154 自动帮你补上了这个优化。在 Chrome 154 稳定版推送到你的用户（预计 2026 年 9-10 月逐步推送）之后，PWA 的 TTFB 会自动改善。

如果你的 SW 用了非常特殊的 fetch handler 逻辑（比如每次都自己构造响应、不是简单透传），可以留意 Chrome DevTools Network 面板里的预加载请求是否正常发出。

下一步

用 Chrome DevTools 看一次 SW 冷启动时间：Network 面板里看 workerStart 到 requestEnd 的差值，Chrome 154+ 应该接近 0
如果配了 NavigationPreload，确认它还在正常工作：有些项目升级 SW 版本时这段代码会丢
别把 SW 只当离线缓存用：结合预加载，它可以让你的 PWA 在弱网下也有接近有网的体验
关注 Chrome 155（预计 2026 年 10 月）：ServiceWorkerAutoPreload 会从小规模 rollout 切换到全量，TTFB 改善会覆盖更多用户

Chrome 154 这次做的事不算酷——没有新 API，没有新概念，只是把一个 2017 年就存在的性能优化默认打开了。但对于那些从来没配过 NavigationPreload 的 PWA 来说，这是今年最该感谢 Chrome 团队的一次”悄悄修好”。

评论区

0 条评论

登录后可评论。