Service Worker同步加载耗时问题咨询（首次集成场景）

刚第一次集成Service Worker就碰到这种加载性能坑确实闹心，我来帮你捋清楚问题根儿在哪，还有怎么解决：

首先拆解下你遇到的现象：

• 正常窗口加载耗时500ms，隐私窗口直接翻倍：这是因为隐私窗口会禁用常规缓存，Workbox的远程脚本需要重新下载，而正常窗口可能已经缓存了Workbox，所以耗时少一些，但核心问题不是缓存，是Service Worker的加载方式。
• 你提到Service Worker是同步加载且耗时全来自Workbox的importScripts()：这才是关键——浏览器在加载Service Worker时，会同步执行importScripts()里的所有脚本，整个过程会阻塞Service Worker的注册、激活流程，而浏览器会等待Service Worker准备就绪后才继续推进页面加载，自然就拖慢了整体耗时。

接下来给你几个针对性的解决办法：

1. 把Workbox和自定义SW代码打包到一起 #

别再用importScripts('https://...')远程拉取Workbox了，直接把Workbox和你的自定义Service Worker代码打包成单个文件：

• 你可以用Workbox CLI工具，执行workbox generateSW或者workbox injectManifest来生成合并后的SW文件；
• 如果用Webpack、Vite这类构建工具，也可以用对应的Workbox插件（比如workbox-webpack-plugin），在构建阶段自动把Workbox合并到你的SW代码里。
  这样一来，只需要加载一个脚本文件，既减少了HTTP请求，也彻底避免了远程加载的延迟问题。

2. 改用异步加载方式（ES模块版SW） #

如果你的项目支持ES模块，可以把Service Worker改成模块类型，用import代替同步的importScripts()：

• 注册SW的时候指定类型：

  navigator.serviceWorker.register('/sw.js', { type: 'module' });
  

• 在SW文件里异步导入Workbox：

  import * as workboxCore from 'workbox-core';
  import { precacheAndRoute } from 'workbox-precaching';
  

这种异步导入不会阻塞Service Worker的初始化流程，浏览器可以在加载SW的同时并行处理页面其他资源，能大幅减少页面加载的等待时间。

3. 用预加载优化远程Workbox的加载（备选方案） #

如果暂时没法打包或者用ES模块，可以在主页面里给Workbox脚本加预加载，让浏览器提前下载：

<link rel="preload" href="https://.../workbox.js" as="script">

这样浏览器会在请求Service Worker之前就把Workbox脚本下载好，当SW执行importScripts()时就能直接从缓存读取，避免同步等待下载的耗时。

最后再提一句：隐私窗口的缓存是临时会话级别的，所以最好还是用打包或ES模块的方式，从根源上解决同步加载的阻塞问题，这样不管是正常窗口还是隐私窗口，加载耗时都会稳定下来。

内容的提问来源于stack exchange，提问作者Tom Piaggio