ServiceWorker提速秘籍：从“请求拦截”到“智能缓存”
认识ServiceWorker：它不是什么神秘技术，就是你的“资源管理员”
很多人一听“ServiceWorker”，觉得带个“Worker”就很高端，其实你可以把它理解成“网页的后台助理”。它独立于网页运行，就像酒店里的后勤团队，前台（网页）忙着接待用户，后台（ServiceWorker）已经把常用的“毛巾”“矿泉水”（静态资源）提前备好。但它有个前提：必须在HTTPS环境下运行（本地开发的localhost除外），这是为了安全，毕竟它能拦截所有网络请求，要是被坏人利用就麻烦了。
我朋友那个电商网站一开始配置ServiceWorker时，踩了个新手常犯的坑：把ServiceWorker文件（通常叫sw.js）放在了/js/文件夹里，结果发现只有/js/目录下的页面能被控制，首页和商品页都不行。后来才知道，ServiceWorker的“管辖范围”是由它的文件位置决定的——放在根目录，就能管整个网站；放在子目录，就只能管那个子目录及以下的页面。所以如果你想让整个网站都用上它，sw.js必须放在网站根目录，这点千万别搞错。
注册ServiceWorker的步骤其实很简单，在你的主JS文件里加几行代码就行：
if ('serviceWorker' in navigator) {
window.addEventListener('load', () => {
navigator.serviceWorker.register('/sw.js')
.then(registration => {
console.log('ServiceWorker注册成功，作用域:', registration.scope);
})
.catch(err => {
console.log('ServiceWorker注册失败:', err);
});
});
}
这段代码的意思是：等页面加载完后，告诉浏览器“去注册/sw.js这个文件当我的助理”。但注册成功不代表马上能用，它还有“安装”“激活”两个阶段。安装阶段就像助理入职培训，这时候你可以告诉它“需要缓存哪些资源”；激活阶段相当于助理正式上岗，这时候可以清理旧的缓存（比如之前版本的资源），避免占空间。
三大缓存策略：什么时候该“存货”，什么时候该“现买”
光注册还不够，ServiceWorker的核心能力是“管理缓存”，但缓存不是瞎存的——存太多占用户空间，存太少没效果。这就需要“智能缓存策略”，就像开超市，日用品（比如酱油、纸巾）可以多囤点，生鲜（比如蔬菜、肉类）就得当天进货。下面这几种策略是我实战中觉得最好用的，咱们一个个说。
先来看个对比表，你可以根据自己的资源类型对号入座：
| 策略名称 | 适用资源类型 | 优势 | 注意事项 |
|---|---|---|---|
| CacheFirst （缓存优先） |
不变的静态资源（CSS、JS、图片、字体） | 加载速度最快，完全不依赖网络 | 资源更新时需改文件名（如style.v2.css） |
| NetworkFirst （网络优先） |
实时数据（商品价格、新闻内容、用户信息） | 保证数据最新，网络不好时用缓存兜底 | 网络慢时可能会有延迟，需设置超时时间 |
| StaleWhileRevalidate （缓存回源） |
半静态内容（博客文章、商品详情） | 先显示缓存内容，后台默默更新缓存 | 首次访问时没有缓存，需要先请求网络 |
为什么这些策略能提速？举个例子：你网站的logo图片，半年才换一次，用CacheFirst策略，用户第一次加载后，以后每次打开网页，ServiceWorker直接从缓存里拿图片，0网络请求，速度当然快。但如果你用NetworkFirst，每次都要去服务器请求，就算图片没变，也得等网络响应，这不是白费功夫吗？
MDN文档里特别强调，缓存策略没有绝对的好坏，要根据资源类型灵活组合（https://developer.mozilla.org/zh-CN/docs/Web/API/Service_Worker_API）。我朋友的电商站就是这么干的：商品图片、CSS/JS用CacheFirst，商品价格用NetworkFirst（毕竟价格会实时变），商品描述用StaleWhileRevalidate（先显示缓存的描述，后台偷偷请求最新的，下次打开就是更新后的了）。这么一组合，既保证了速度，又不会让用户看到旧数据。
拦截请求：让每个字节都不浪费
ServiceWorker最核心的能力其实是“拦截网络请求”，就像小区门口的保安，所有“快递”（网络请求）都要经过它检查。它会根据你设定的规则，决定是从缓存拿资源，还是去网络请求，或者两者结合。
比如用户请求一张图片，ServiceWorker的工作流程是这样的：
我之前帮一个博客作者优化网站，他的文章页有很多历史文章，读者经常反复查看。原来每次打开文章，连3年前的图片都要重新加载，后来用ServiceWorker拦截图片请求，对所有发布超过7天的文章图片用CacheFirst，结果图片加载时间从平均500ms降到50ms以内，读者反馈“感觉页面滑起来都变流畅了”。
这里有个细节要注意：拦截请求时，一定要处理“请求失败”的情况。比如用户在地铁里没信号，请求网络肯定失败，这时候如果没缓存，页面就白屏了。所以在sw.js里的fetch事件监听函数里，一定要加个catch：
self.addEventListener('fetch', event => {
event.respondWith(
fetch(event.request)
.then(networkResponse => {
// 把网络响应存到缓存
caches.open('my-cache-v1').then(cache => cache.put(event.request, networkResponse.clone()));
return networkResponse;
})
.catch(() => {
// 网络失败时，返回缓存的内容（如果有的话）
return caches.match(event.request) || caches.match('/offline.jpg'); // 没缓存就返回默认图片
})
);
});
这样就算断网，用户至少能看到之前缓存的内容，或者一张“离线提示”图片，比白屏体验好太多。
离线缓存实战：从“断网白屏”到“随时可用”
缓存范围：不是所有资源都该“囤货”
实现离线功能，第一步是明确“哪些资源需要缓存”。不是所有东西都适合缓存，比如大视频文件（缓存了占用户空间）、实时API数据（缓存了会显示旧内容）。一般来说，值得缓存的资源包括：HTML页面（至少是首页和关键页面）、CSS/JS文件、图片图标、字体文件、离线提示页面（比如offline.html）。
我之前帮一个教育类网站做离线课程页面，他们的用户经常在地铁上学习，要求断网也能看之前缓存的课程。一开始技术团队把所有资源都缓存了，包括100多MB的视频，结果用户手机空间告警，纷纷卸载。后来调整了策略：只缓存课程大纲（HTML）、课件图片（CSS/JS），视频用“按需缓存”——用户点击“缓存本课程”按钮后，才缓存对应的视频，而且设置了缓存有效期（30天），过期自动清理，问题才解决。
怎么定义缓存范围？在sw.js的install事件里，用caches.open()创建一个缓存仓库，然后用cache.addAll()添加需要缓存的资源列表：
self.addEventListener('install', event => {
// 缓存关键资源，注意：addAll里的资源如果有一个加载失败，整个缓存都会失败
const cacheAssets = [
'/',
'/index.html',
'/styles.css',
'/app.js',
'/logo.png',
'/offline.html' // 离线时显示的备用页面
];
event.waitUntil(
caches.open('my-cache-v1') // 缓存名称最好带版本号，方便后续更新
.then(cache => cache.addAll(cacheAssets))
.then(() => self.skipWaiting()) // 安装成功后立即激活，不用等旧的ServiceWorker退出
);
});
这里有个坑：cache.addAll()是“全有或全无”的——如果列表里有一个资源加载失败（比如404），整个缓存过程就会失败。所以如果你不确定某个资源是否一定存在，最好用forEach单个添加，失败了也不影响其他资源：
cacheAssets.forEach(asset => {
cache.add(asset).catch(err => console.log(缓存${asset}失败:, err));
});
离线降级：断网了，至少给用户一个“交代”
就算缓存了资源，也难免遇到“缓存里没有的请求”（比如用户第一次访问某个页面就断网）。这时候不能让用户看到浏览器默认的“无法访问此网站”错误页，而是要显示一个友好的离线提示页面，告诉用户“现在没网，但你之前看过的内容在这里哦”。
我朋友的电商网站就做了个很贴心的离线页面：顶部写“网络开小差啦～”，中间显示用户最近浏览过的5件商品（从IndexedDB里取，后面会说），底部放个“刷新重试”按钮。用户就算断网，也能看到之前看过的商品，还能点按钮重试，比白屏体验好太多。
实现离线页面的关键是：在fetch事件失败时，返回离线页面。比如在前面提到的fetch事件监听函数里，当网络请求失败且缓存里没有对应资源时，返回/offline.html：
.catch(() => {
// 先尝试返回缓存的请求资源，如果没有，返回离线页面
return caches.match(event.request) || caches.match('/offline.html');
});
但光有离线页面还不够，最好能显示一些“有用”的内容。比如用Storage API（localStorage或IndexedDB）记录用户最近浏览的页面、收藏的内容，离线时从Storage里取出来显示。我帮那个博客作者做的离线页面，就会显示用户“最近阅读的3篇文章标题”，很多读者反馈“虽然没网，但能回顾之前看的文章，还挺实用”。
Google Developers博客里提到，良好的离线体验能让用户回访率提升30%（https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/service-worker-caching-strategies）。他们自己的Chrome开发者文档网站，就是用ServiceWorker实现了完全离线访问——你甚至可以在断网时打开文档，查看所有之前加载过的API说明，这对经常需要查文档的开发者来说太香了。
缓存更新：别让用户永远看到“旧内容”
缓存最大的问题是“内容更新”——如果你的CSS文件更新了，但用户的缓存里还是旧版本，就会出现样式错乱。这时候就需要“缓存版本控制”，最简单的办法是给缓存名称加版本号，比如从“my-cache-v1”升级到“my-cache-v2”。
当你更新了资源，比如改了CSS，就把sw.js里的缓存名称从v1改成v2，然后在activate事件里清理旧缓存：
self.addEventListener('activate', event => {
event.waitUntil(
caches.keys().then(cacheNames => {
return Promise.all(
cacheNames.map(name => {
// 如果缓存名称不是当前版本，就删除
if (name !== 'my-cache-v2') {
return caches.delete(name);
}
})
);
}).then(() => self.clients.claim()) // 激活后立即控制所有打开的页面
);
});
这样用户访问时，ServiceWorker会安装新版本，激活时删除旧缓存，下次请求就会加载新的CSS文件了。但这里有个“时间差”问题：用户可能在你发布新版本后，没关闭旧页面，这时候旧页面还是用旧的ServiceWorker。解决办法是在注册ServiceWorker时，监听“controllerchange”事件，提示用户刷新：
navigator.serviceWorker.register('/sw.js').then(registration => {
registration.addEventListener('updatefound', () => {
const newWorker = registration.installing;
newWorker.addEventListener('statechange', () => {
if (newWorker.state === 'installed') {
// 有新版本可用，提示用户刷新
alert('网站有更新，点击确定刷新获取最新内容');
// 用户点击确定后，激活新的ServiceWorker
newWorker.postMessage({ action: 'skipWaiting' });
}
});
});
});
我朋友的电商网站就吃过“缓存没更新”的亏——双11前改了促销活动的按钮样式，结果有用户反馈“按钮还是旧的，点了没反应”，后来才发现是缓存没更新，赶紧加上版本控制和更新提示，才没影响活动效果。
最后教你个验证缓存是否生效的小技巧：打开Chrome开发者工具，切换到“Application”标签，左边栏找到“Service Workers”，勾选“Update on reload”（刷新时更新），然后刷新页面，就能看到ServiceWorker的注册状态；再点“Cache Storage”，就能看到你创建的缓存仓库和里面的资源，点击资源还能预览内容，确保缓存的是对的。如果发现缓存里有旧资源，就检查缓存名称是不是没更新，或者activate事件里有没有删除旧缓存。
如果你还没试过ServiceWorker， 从自己的个人项目开始练手，先缓存静态资源（CSS、JS、图片），看看加载速度有没有变化。如果遇到问题，欢迎在评论区问我，我看到都会回。记住，前端性能优化不是一次性的事，而是持续迭代的过程，ServiceWorker只是其中一个工具，但用好它，能让用户体验提升一大截。
你知道吗，ServiceWorker之所以要求HTTPS环境，本质上是因为它的“权力”太大了——它能直接拦截网页的所有网络请求，包括你提交的表单数据、加载的图片资源，甚至API接口返回的信息。如果在HTTP这种不安全的环境下运行，万一有坏人在中间篡改了ServiceWorker脚本，就能轻松窃取用户数据或者返回伪造的内容，那后果可就严重了。就像你家请了个管家，肯定得先确认他身份可靠（HTTPS加密），才敢把家门钥匙（网络请求控制权）交给他吧？
不过开发阶段有个“特殊通道”——localhost本地环境是允许HTTP的，这是浏览器特意留的方便之门。我去年帮朋友调试一个官网时，一开始在本地用http://localhost:3000测试ServiceWorker，注册、缓存都好好的，结果部署到服务器时没开HTTPS，打开控制台一看全是红色报错，ServiceWorker根本注册不上。后来才反应过来，生产环境必须得HTTPS，赶紧让运维同事配置了SSL证书，这才解决问题。所以记住，本地开发随便玩，上线必须穿“HTTPS安全衣”，这是铁规矩。
ServiceWorker必须在HTTPS环境下运行吗？
是的，ServiceWorker通常需要在HTTPS环境下运行（本地开发的localhost除外）。这是出于安全考虑，因为ServiceWorker具有拦截网络请求、管理缓存等核心能力，HTTPS能防止恶意脚本篡改请求或缓存内容，确保用户数据和资源的安全性。
如何确保ServiceWorker缓存的资源能及时更新？
可通过“缓存版本控制”实现资源更新：给缓存名称添加版本号（如“my-cache-v1”“my-cache-v2”），当资源更新时，将缓存名称升级到新版本；在ServiceWorker的activate事件中，通过caches.delete()清理旧版本缓存；同时可监听更新事件，提示用户刷新页面以激活新版本，避免用户看到旧内容。
ServiceWorker和传统的HTTP缓存有什么区别？
传统HTTP缓存（如Cache-Control、ETag）由服务器通过响应头控制，规则固定且功能有限，无法主动拦截请求或实现离线访问；ServiceWorker则由开发者完全控制，可灵活定义缓存策略（如CacheFirst、NetworkFirst），主动拦截所有网络请求，结合Storage API实现离线功能，更适合复杂的前端性能优化场景。
哪些浏览器支持ServiceWorker？
目前主流浏览器均支持ServiceWorker，包括Chrome、Firefox、Edge（Chromium内核版本）、Safari 11.1及以上版本。Internet Explorer（IE）不支持ServiceWorker。实际开发中可通过caniuse等工具查询具体浏览器版本的支持情况，确保覆盖目标用户群体的浏览器环境。
使用ServiceWorker会影响网站的安全性吗？
只要遵循安全最佳实践，ServiceWorker不会影响网站安全性。HTTPS环境已为其提供基础安全保障；其“管辖范围”（scope）由文件位置决定，避免越权控制；开发者通过验证缓存资源来源、限制敏感数据缓存等措施，可进一步降低风险。MDN等权威文档也指出，合理使用ServiceWorker反而能提升网站的安全性和可靠性。
