前端缓存实战：强缓存、协商缓存与Service Worker全解析

前端缓存最被低估的性能优化技巧我说句可能得罪人的话很多团队做前端性能优化把精力全砸在代码压缩、路由懒加载、图片裁剪上一顿操作猛如虎结果线上二次访问首屏还是慢。原因很简单——它们把最便宜、见效最快、回报率最高的一环给漏了这一环就是缓存。缓存不是一个“锦上添花”的配置项它是前端性能优化的地基。地基打好了后面做的压缩、拆包、预加载才站得住。而且它不止影响性能还直接影响服务器压力和用户体验。今天这篇文章我就把缓存从原理到落地、从配置到排错整条链路讲透不管是刚入门的前端还是已经在做性能专项的负责人都能从里面找点能直接用的东西。1. 缓存的回报率为什么说它是性能优化里被低估的“免费午餐”1.1 性能优化三板斧里最容易漏掉的一板先看一个直观场景用户第一次打开你的页面走了完整的网络请求HTML、JS、CSS、图片加起来好几MB耗时两三秒。第二次打开如果不做任何缓存处理他会原封不动再把这几MB下载一遍耗时和第一次几乎一样。但如果缓存策略到位第二次打开可能只要一两百毫秒页面内容直接从本地加载连网络请求都不用发。差距十倍以上。这不是什么黑科技就是HTTP缓存和浏览器存储机制的正常发挥。我见过不少团队做性能优化清单时列了十几项——资源瘦身、SSR、预渲染、骨架屏、懒加载、CDN加速……唯独没有缓存。等上线一看首屏指标确实好了点但用户二次访问的体验没什么变化服务器请求数也下不来。这种努力属于典型的“事倍功半”——省了传输体积却没省重复传输。1.2 缓存真正省下的三笔账缓存的价值不只是“快了一点”它实际在三个方面同时贡献收益第一时间账。重复访问时页面加载耗时大幅下降这块直接对应到用户体验指标。对于资讯类、工具类、电商这类用户重复访问率高的产品缓存带来的体感提升比任何动画优化都明显。第二流量账。移动端用户的流量不是免费的。一个3MB的页面每次打开都重新下载一个月下来可能吃掉几百MB。缓存做好之后首次加载以外基本不再重复消耗流量这点在弱网环境下尤其重要。第三服务器账。后端同学最头疼的就是流量高峰。静态资源的请求如果每次都打到源站QPS压力会成倍放大。缓存命中之后大量请求在浏览器本地或者CDN边缘节点就被消化掉了真正回源的数量可能只有原来的十分之一。1.3 缓存的本质判断“内容到底变没变”要理解缓存先记住一句话缓存的本质是对“资源是否发生了变化”的判断。浏览器拿到一个资源处理方式无非三种本地直接用、问一下服务器能不能用、老老实实重新下载。这三种方式对应强缓存、协商缓存和无缓存。判断触发哪条路径靠的还是响应头里那一组缓存相关字段。你把这几个字段理解了缓存策略基本就懂了大半。后面我会把每个字段的使用边界、常见误配包括浏览器内部的那些小动作都拆开讲清楚。2. HTTP缓存层的两张“王牌”强缓存与协商缓存2.1 强缓存Cache-Control 与 Expires 的正确姿势强缓存的意思是浏览器在本地副本还没过期之前根本不会发请求。它不跟服务器通信直接本地硬读。开发者在Network面板里看到的from memory cache、from disk cache就是在走强缓存。现在主流的强缓存配置就一个字段Cache-Control配合max-age指定存活时间单位是秒。比如Cache-Control: public, max-age31536000, immutable一年过期内容只要没改名浏览器这一年里都会直接用本地副本。immutable的意思是“这资源根本不会变”主要用于明确告知浏览器不要去做那些多余的重验证。以前还有个Expires字段它是个绝对时间。问题是服务器时间和用户本机时间一旦不一致判断就会错乱。所以现在Expires基本被Cache-Control取代了两者同时出现时Cache-Control优先。这里有一个容易被忽略的点Cache-Control里public、private和no-store的语义完全不同。public任何中间节点都能缓存包括CDN和代理服务器。private只能浏览器本地缓存中间节点不能缓存。登录态相关的接口或者带个人信息的响应应该加这个。no-store所有环节都不准缓存强制每次全量下载。断网、弱网下想快速拿到上一次的界面private通常就已经够用public适合静态资源和CDN配合使用。这两者别搞混。2.2 协商缓存Last-Modified 与 ETag 的信任博弈强缓存过期之后浏览器会发一个带验证条件的请求给服务器服务器判断内容是否变化没变化就返回一个空身体这就是协商缓存。协商缓存靠两对头配合工作Last-Modified/If-Modified-Since是时间戳方案。服务器上次修改时间跟着响应头返回浏览器再次请求时带上If-Modified-Since: 上次的时间。服务器比较一下修改时间如果没变返回304 Not Modified空body如果变了就返回200加新内容。ETag/If-None-Match是校验值方案。这个值通常是内容的哈希、版本号或者mtime组合服务器生成后随响应返回。浏览器再次请求带上If-None-Match服务器比对一致就304不一致就200。实际使用中ETag比Last-Modified更可靠因为时间戳有几个天坑某些文件系统只有秒级精度一秒内多次修改无法区分服务器和浏览器时钟可能有偏差负载均衡下多个源站的修改时间可能不一致。而ETag是内容校验不存在这些问题。不过也别迷信ETag。如果资源内容大到几GB每次对比都要重新计算ETag值消耗也不小。标准做法是静态资源用强缓存变化不频繁但需要及时感知的资源用协商缓存或者ETag Last-Modified同时返回给浏览器来判断。缓存判断过程可以总结成一张流程表场景浏览器动作响应码实际效果强缓存未过期不发请求直接用本地200 (from cache)秒开强缓存过期协商未命中携带验证头请求304省下载仍有往返强缓存过期内容已变正常请求200正常下载新内容无缓存配置每次全量请求200重复下载2.3 容易被忽略的“启发式缓存”大家容易漏掉一个自动生效的缓存机制启发式缓存。即使服务器完全没返回Cache-Control浏览器自己也会根据Last-Modified算出一个时间窗口做本地缓存一般是修改时间和当前时间差的10%左右。比如一个HTML页面Last-Modified是五天前浏览器可能自作主张缓存12小时。开发的时候改动文件刷新页面怎么都看不到最新效果大概率就是这个在作怪。解决思路很简单所有要动态更新的资源明确给出Cache-Control: no-cache或者精确的max-age不要依赖浏览器的自我发挥。no-cache不是“不缓存”而是“每次用之前先问服务器”这个语义很多人搞反了。2.4 一套可以直接抄的响应头配置说再多不如给一份参考。以下是我在项目里用着比较顺的静态资源配置覆盖了主流的几种资源类型资源类型Cache-Control 配置说明HTML页面Cache-Control: no-cache保证每次请求都会回到服务器校验避免改版不生效JS/CSS带hash文件名Cache-Control: public, max-age31536000, immutablehash变了文件名才变文件本身不变可以放心长缓存图片/字体/媒体Cache-Control: public, max-age2592000一个月左右强度合理换图后大概率能被新URL或协商流程覆盖接口请求Cache-Control: no-cache或private, max-age60根据业务容忍度决定需要登录的一般不建议公共缓存登录态/隐私页面Cache-Control: private, no-store防止中间层缓存用户个人信息这套配置的核心逻辑就一句话对会变的东西每次都验证对不变的东西尽量不验证。如果你的项目里什么响应头都没配建议先从这份开始收益立竿见影。3. 应用层缓存的进阶思路从浏览器存储到 Service Worker3.1 各种浏览器存储的定位和实际适用范围HTTP缓存管的是“资源”而业务层面还经常要“省着点用”数据接口的结果或者用户产生的数据这时候就需要应用层的存储方案了。localStorage是最常用的但它有它的毛病同步读写主线程上有大字符串操作时会卡顿容量小标准是5MB左右而且只能存字符串。如果只是存用户偏好、Token、轻量配置它足够好使拿它做接口数据缓存就不太合适了数据量一大很快触顶而且没法像HTTP缓存那样自动过期。sessionStorage是会话级的标签页关了就没了适合存草稿、临时步骤状态这类天然跟会话绑定的数据。IndexedDB才是应用层数据缓存的正确姿势。它是异步的、容量大通常几百MB甚至更多、支持结构化数据和索引查询适合做离线数据存储、大列表缓存、图片二进制缓存、用户行为队列等。虽然API偏底层、封装略显啰嗦但配合fake-indexeddb这种工具做单元测试也是标准操作成熟度完全没问题。3.2 Cache API 与 Service Worker 的缓存命中逻辑localStorage和IndexedDB解决的是“应用逻辑层”的数据复用但页面本身的HTML、JS、CSS这些资源还是得靠HTTP缓存或者 Service Worker 来接管。Service Worker 是浏览器里的一个独立线程能拦截页面发出的所有请求然后自己决定怎么回应。要配合它工作通常会用到Cache API给请求和响应建一个可编程的缓存仓库。核心逻辑大概是这样首次加载时页面正常请求资源安装完 SW 之后每次fetch事件都会先看本地Cache里有没有对应的response有就直接返回没有再去网络请求拿到之后塞进Cache里。一个最简易的缓存优先示例self.addEventListener(install, (event) { event.waitUntil( caches.open(my-site-v1).then((cache) { return cache.addAll([/index.html, /assets/js/main.js, /assets/css/main.css]); }) ); }); self.addEventListener(fetch, (event) { event.respondWith( caches.match(event.request).then((response) { if (response) { return response; } return fetch(event.request).then((networkResponse) { const cacheCopy networkResponse.clone(); caches.open(my-site-v1).then((cache) { cache.put(event.request, cacheCopy); }); return networkResponse; }); }) ); });这段代码能跑但只是入门版。生产环境里要考虑网络失败时的兜底要处理缓存清理、版本升级更要注意不能让所有请求都被SW接管比如跨域的第三方接口、上报打点的请求就不适合拦截缓存。这里有一个很多人都会踩的坑SW里cache.put之前必须先response.clone()。因为Response流是一次性的直接put会把响应体消费掉后面页面拿来用的时候就没数据了会报错。这是个很典型的分布式代码问题排查半天才发现是clone漏了。3.3 离线兜底为什么大部分页面其实不需要醒目的离线提示做了 SW 缓存之后最直观的价值是能离线访问。但对大多数内容型页面来说离线这个词本身就不敏感。真正有价值的是缓存优先策略带来的二次访问速度提升以及弱网环境下的稳健性。比如某个用户在地铁里信号忽好忽坏正常无线下大概率是白屏加载失败。但有SW缓存即便网络请求超时还能用上一次成功保存的页面框架和样式先把界面渲染出来再通过后台同步慢慢补数据。这种体验上的提升比在页面上挂一个“离线模式”提示要重要得多。升级SW时要注意版本管理最稳妥的方式是给SW文件名加版本号比如sw.20250201.js配合页面里的navigator.serviceWorker.register更新。不要指望用户会自动得到最新SW代码浏览器的 SW 更新策略本身就有不少延迟。后面排错章节我会专门展开。3.4 什么时候不要上 Service Worker这个话可能很多人不爱听但我还是要说不是所有项目都得上 SW。SW 引入的复杂度是真实的尤其是跨域请求处理、本地开发调试、浏览器缓存策略冲突这几个环节踩坑时间往往远超收益。如果你的页面是纯内容展示、访问频率不高或者团队没有足够的精力维护离线策略那先把HTTP缓存做扎实就够了。对大多数中后台项目SW的收益甚至接近零因为用户每次打开都大概率是同一套桌面环境网络稳定强缓存已经能解决大部分问题。判断标准就一条你的用户里有没有大比例是重复访问、弱网、移动场景有SW值得上没有先把 HTTP 缓存这碗饭吃完再说。4. 工程化落地缓存策略不是配置是版本管理4.1 静态资源版本化为什么“文件名哈希”比“强制更新”好用强缓存配置好之后出现一个新问题我给JS和CSS设了max-age31536000一年都不重新请求那下次发布了新版本用户拿到的还是去年的旧文件怎么办答案非常明确让文件名跟着内容走。内容变了文件名哈希就变浏览器自然发新请求内容没变文件名不变一年都走本地缓存。这套机制配合现代构建工具几乎是标准配置。打开任意一个项目构建产物会看到类似app.8f3c4d9e.js、vendor.a2b1c0d3.css这样的文件。那个八位十六进制就是基于文件内容算出的哈希。构建一次哈希匹配一次发布版本只见新文件名不见旧文件的新网络请求。使用文件名哈希后有几个和缓存直接相关的好处旧缓存永远不会失效因为内容一变URL就换了一套。不同版本同时在线也不互相污染老用户继续用老资源新用户拉新资源互不干扰。回滚变得简单改回旧版本对应的hash引用即可缓存层完全不需要操作。4.2 分级缓存策略HTML短缓存静态资源长缓存理解了文件名哈希就可以正式设计一套分级缓存策略了。核心原则是HTML千万不能长缓存静态资源尽量长缓存。页面HTML本身是不带hash的用户访问https://site/index.html拿到的是不包含版本信息的入口文件。如果HTML被强缓存了引用新hash的标签就永远无法到达页面直接就卡在旧版本出不来。正确做法是给HTML配Cache-Control: no-cache让它每次都到服务器确认最新版本确认的时候再带上新hash的静态资源URL静态资源就能安全享受一年的强缓存。对于静态资源推荐一个组合Cache-Control: public, max-age31536000, immutable配合文件名哈希这就是前端静态资源缓存的黄金组合。按这种策略用户首访会全量加载一次之后除非有新版本发布否则所有资源都走本地缓存。服务器压力降下来页面秒开体验直线上升。4.3 用 DevTools 精确判断缓存命中来源排查缓存问题时最喜欢的工具还是浏览器的开发者工具但要注意Network面板里那几栏状态信息每个都暗藏玄机。随手打开一个已经访问过的页面Network面板的类型列会看到几种不同的来源类型含义说明from memory cache浏览器进程内存里的副本当前页面或tab内刚用过的资源最快但刷新页面后可能就没了from disk cache磁盘上的缓存副本跨会话复用速度接近本地读取from service workerSW主动返回的缓存不经过网络栈走SW逻辑304 Not Modified协商缓存生效服务器确认没变节省了下载body200真·重新下载没有命中缓存或服务器确认内容有变遇到指标异常或功能异常时先看这一列基本就能锁定是缓存策略问题还是代码问题。值得多留个心眼的是from memory cache和from disk cache的命中情况背后还受内存容量、Disc缓存分区策略影响并不完全等同于你配置了强缓存就会命中。4.4 三个经典踩坑案例从现象到修复的完整链路案例一发布后用户还停在旧版本。现象配置了文件名哈希也发布了新版本运维那边确认服务器上新文件都在但用户端还是加载旧版。排查看HTML响应头里是不是带了Cache-Control: max-age3600。如果有那就是HTML本身被缓存了。首页入口文件的缓存策略必须拆出来单独配置no-cache优先。另外还要检查代理层或CDN是否覆盖了HTML的缓存策略CDN侧的缓存时间可能比响应头更长。案例二Service Worker 缓存了旧版列表数据。现象开发环境一切正常线上小程序和App里看到列表还是昨天的数据怎么刷新都没用。排查打开Application面板看Service WorkerDevTools还提供了Update on reload选项勾上之后每次刷新都会强制检查更新SW但线上普通用户没法这么操作。根本原因还是SW缓存策略设计得太粗糙所有GET请求都缓存了列表数据也被接了进去。数据类请求要么不缓存要么缓存时设置过期时间或者通过网络优先策略网络失败才用缓存。案例三跨域资源加CDN后出现双份缓存头。现象图片资源在CDN上配置了Cache-Control: max-age86400但源站顺手也返回了一个Cache-Control: no-cache。结果CDN直接用了no-cache强缓存完全没生效。排查查回源响应头和CDN节点响应头是否一致。这类资源建议源站配置改为CDN的配置逻辑并在CDN控制台开启“强制缓存优先”保证中间层的缓存策略和源站统一否则会出现“浏览器忽略强缓存回源每次发现变化”的低效率局面。这些坑的共同点是问题都不在“缓存配置”本身而是配置和上层链路不匹配。排查思路还是得从请求链路逐层看别只盯着页面代码看。4.5 上线发布与缓存“脏包袱”的处理节奏就算配置全部正确上线时如果不注意节奏用户侧的缓存也可能出现“脏包袱”。我习惯的做法是发版前一晚在预发环境验证新版本页面和资源重点确认HTML的Cache-Control是否生效静态资源hash是否变了发版后立刻在线上打开页面在Network面板里确认用户侧会正常拿到新资源新文件名确实引到CDN或源站了。这一步是踩过太多次坑才养成的习惯。如果用户基数很大有些老用户的本地缓存可能存在很长时间的残留。遇到这类问题一个简单粗暴的兜底是给静态资源URL加一个临时参数如?v20250213强制新请求但这种方式会绕过哈希且容易忘改不建议作为常态方案。正解永远是文件名哈希 HTML不缓存这套组合拳。5. 缓存与性能指标的实测记录一套可复现的验证方法5.1 验证思路和指标选择判断缓存策略是否生效最直接的指标不是Lighthouse那类综合评分而是以下几个首次加载与二次加载耗时对比重复访问时请求中实际发往服务器的数量变化请求在Network面板中的来源分布from cache / from SW / 304 / 200单次请求的Transfer size 与 Resource size 对比5.2 我在模拟项目上的实测无缓存、强缓存、加SW的三级对比我在一个模拟项目X里搭了一个简单的页面包含约2.4MB的静态资源JS脚本、样式表、若干图片在三种策略下做对照测试。无缓存时首访约 3.1s二次访问约 2.9s几乎没有任何差别每个请求都要通过网络下载服务器累计收到几十个静态资源请求。加了Cache-Control: public, max-age31536000和文件名哈希之后首访约 2.6s因CDN边缘优化略有下降二次访问直接降到 0.3sNetwork面板里几乎全部请求标记为from disk cache服务器收到的请求数接近零。再加一层Service Worker缓存之后二次访问的耗时进一步压缩约为 0.15s而且断网状态下还能正常渲染页面首屏。代价是SW的维护复杂度和调试成本明显上升。三次测下来结论很清晰HTTP缓存把90%的分拿到了SW更像是在此之上的锦上添花。5.3 三个容易误导人的指标做性能汇报时有几个指标很容易被误读需要心里有数。第一个是TTFB。它衡量的是“浏览器发出请求到收到第一个字节的时间”但这个时间反映的是网络往返和服务器处理不包含本地缓存命中的那一部分。二次访问走强缓存时TTFB根本不会产生记录用TTFB对比缓存优化效果不大合适。第二个是请求总数。优化前请求总数可能是30个优化后变成4个会给人一种“做了很多事”的感觉。但真正该关注的是“实际回源了多少请求”、“多少请求完全没有走网络”。只统计总数而不看来源容易被表象骗到。第三个是Lighthouse的性能分。它模拟的是首次加载的冷启动过程不会体现回流用户的体验差异。而缓存恰恰是为重复访问服务的如果只盯首访分数缓存带来的收益几乎显示不出来。正确做法是结合真实用户采集数据真实用户访问数据里的二次访问耗时、请求回源率来评估。6. 做缓存优化后我沉淀下来的几点习惯最后聊点很私人的体会。缓存是个越做越顺手的活但也是越做越容易踩坑的活我现在基本养成了三个习惯。第一个习惯是把缓存策略当作代码的一部分来做评审。任何影响页面或资源的缓存头配置都要进测试用例线上链路也必须有监控指标辅助判断不能随手加个max-age就完事。第二个习惯是排查问题时永远先打开Network面板看“来源列”。这比看任何性能报告都快几秒就能定位是强缓存、协商缓存还是SW的问题。第三个习惯是能让用户侧动的东西尽量少折腾页面逻辑。缓存策略调整不要通过发版改代码的方式去做而是通过配置中心或CDN控制面板快速调整因为这类问题的时效性很强用户反馈“页面打不开/看不到新内容”时你还在写代码改配置就太慢了。缓存做好的项目老用户访问几乎感受不到加载过程甚至断网也能看到大致轮廓这种稳定感是普通压包优化给不了的。别让这项最基础的优化一直躺在角落里积灰了。