Chrome中Service Worker为何比普通网络请求更慢？

核心原因分析 #

• Service Worker唤醒开销：Chrome对Service Worker的生命周期管理较为严格，长时间无请求时会将其休眠甚至回收。当新请求触发时，需要重新唤醒并初始化Service Worker，这个过程会带来100-600ms的额外延迟。而Safari的休眠策略更宽松，唤醒开销更低，因此性能表现更稳定。
• 线程切换开销：Service Worker运行在独立的后台线程，主线程触发fetch事件后，需要跨线程传递请求和响应数据，即使是内存中的响应，线程通信也会产生固定开销，在Chrome的线程调度机制下，这种开销可能出现较大波动。
• Chrome资源调度优先级：Chrome会限制后台Service Worker的运行优先级，当浏览器资源紧张（如多个标签页运行、CPU负载高）时，Service Worker的事件处理会被延后，导致响应时间变长。

优化方案 #

• 维持Service Worker活跃状态：通过页面定期发送心跳请求，防止Service Worker被休眠或回收。示例代码：

// 页面侧心跳逻辑
setInterval(() => {
  fetch('/sw-heartbeat', { keepalive: true }).catch(() => {});
}, 30000); // 每30秒发送一次心跳

// Service Worker侧处理心跳
self.addEventListener('fetch', (event) => {
  if (event.request.url.includes('/sw-heartbeat')) {
    event.respondWith(new Response('pong', { status: 200 }));
  }
});

• 简化fetch事件处理逻辑：提前将URL匹配规则缓存为内存中的正则表达式或映射表，避免每次请求时执行重复的匹配计算，减少事件处理耗时。
• 开启Navigation Preload：该功能可在Service Worker唤醒的同时并行发起请求，即使使用缓存响应，也能抵消部分唤醒延迟。示例代码：

// Service Worker中启用Navigation Preload
self.addEventListener('activate', (event) => {
  event.waitUntil(self.registration.navigationPreload.enable());
});

// fetch事件中利用预加载
self.addEventListener('fetch', (event) => {
  if (event.request.mode === 'navigate') {
    event.respondWith(
      event.preloadResponse.then(preloadRes => preloadRes || caches.match(event.request))
    );
  }
});

• 检查Chrome后台限制：用户可在chrome://flags/#service-worker-background-timeout中查看并调整Service Worker的后台超时设置，延长活跃时间。

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