做了这么多年Web性能优化我越来越觉得“资源加载与缓存机制”才是整个前端性能体系的真正命门。很多朋友把性能优化等同于压缩图片、开启Gzip但真正影响首屏体验的往往是浏览器怎么“取”资源、怎么“存”资源、怎么“判断”资源该不该重新下载这一整套链路。这一篇我把这套机制从头到尾捋一遍包括我自己踩过的坑、排查过的线上事故内容主要针对Web开发场景前端工程师、后端工程师和做性能治理的朋友都适合读。1. 资源加载浏览器“取货”的全流程先想一个问题用户在地铁里打开你的H5页面从按下手指到页面首屏出现这一两百毫秒里浏览器到底干了多少活很多人只知道“发了请求、拿到HTML、解析渲染”但实际上每一次资源加载都像一个完整的供应链环节远比想象中多。1.1 从URL输入到首字节中间发生了什么把“输入URL到页面可交互”这一整段拆开看资源加载其实可以分为五个大阶段。第一个阶段是DNS解析。浏览器不知道www.example.com在哪台服务器上必须先向DNS服务器问路拿到对应的IP地址。这个环节平时看着快但公共DNS被污染、本地DNS缓存失效、用了非常规端口的时候耗时可能飙到几百毫秒甚至超时。第二个阶段是TCP连接。拿到IP之后浏览器要和服务器建立TCP连接通常需要三次握手。别小看这三次握手——每一轮都要跨越大半个互联网RTT往返时延在移动网络下常常要50到100毫秒。如果页面使用了十几个域名光建立连接就是一笔不小的开销。第三个阶段是发送HTTP请求与等待响应。浏览器把请求头发出去服务器处理并返回响应。这个阶段除了网络传输本身还会被服务器的处理能力、反向代理的转发效率、数据库查询时间影响。用户感知到的“白屏时间”很大一部分就花在这里。第四个阶段是解析HTML并加载子资源。HTML到手之后浏览器开始逐行解析遇到link、script、img这类标签就会继续发起新的资源请求。注意这可不是解析完HTML才开始而是边解析边加载所以页面里子资源的数量和顺序直接影响加载完成的时间。第五个阶段是渲染与合成。CSS和JavaScript都到位之后浏览器构建DOM树、CSSOM树合并成渲染树最后绘制像素到屏幕上。这五个阶段环环相扣任何一个环节出问题用户感知到的都是“卡”和“慢”。但有意思的是绝大多数性能问题都不在第五阶段而出在前四个阶段——尤其是重复的资源请求。1.2 为什么说“加载”是性能的关键路径我早年做性能优化时也犯过“过度关注渲染”的毛病把大量精力花在优化CSS选择器、减少重排重绘上结果首屏速度提升极其有限。后来用Performance面板一测才发现真正拖后腿的是一堆重复加载的资源——同一个用户在一个会话里反复请求同一张图片、同一个脚本每次都完整走一遍DNS、TCP、HTTP白白浪费了一半以上的加载时间。也就是说资源加载优化的本质就两件事让该加载的尽快加载让不该重复加载的完全不加载。前者靠并发、预加载、优先级调度后者靠缓存机制。理解了这一点再去学什么Cache-Control、ETag、Service Worker就知道每一样工具到底在解决哪个环节的问题了。2. 缓存机制的地基强缓存与协商缓存聊到缓存很多人第一反应是“浏览器缓存”但严格来说HTTP缓存机制分两层——强缓存和协商缓存。这两者执行时机不同、判断逻辑不同搞混了就会出现“明明改了代码用户还是旧页面”的经典事故。2.1 强缓存浏览器说了算根本不问服务器强缓存的逻辑是浏览器直接根据响应头里的Cache-Control或Expires判断资源有没有过期如果没过期直接用自己的缓存副本连请求都不发。我在项目里最常用的就是Cache-Control的max-age指令。比如给一张图片设置Cache-Control: max-age31536000意思是从第一次拿到这个资源起的一年内浏览器都不会再向服务器发请求。这个机制对静态资源简直是救命稻草——同一张Logo图用户一周访问你十次理论上只需要下载一次。Expires是Cache-Control出现之前的旧方案指定一个绝对过期时间比如Expires: Fri, 21 Dec 2026 15:00:00 GMT。但它有个硬伤服务器时间和用户本地时间不一致就会出错。所以现在主流方案是Cache-Control优先Expires只作为兼容降级。这里有一个我反复跟团队强调的坑强缓存一旦生效完全没有请求到服务器。如果你给某个接口设了max-age3600那这一个小时里用户那边不管数据怎么变拿到的都是旧的。动态接口不要随便加强缓存否则排查问题的时候你会被“明明改了代码不生效”坑到怀疑人生。2.2 协商缓存带着凭证去问服务器强缓存的时间过期了怎么办这时候进入协商缓存流程。浏览器带上缓存的“凭证”去问服务器这个资源我手头有一个旧版本变没变没变就返回304我继续用旧的变了就返回200和新内容。协商缓存的核心是两对头信息。一对是基于时间的请求头里的If-Modified-Since对应响应头里的Last-Modified服务器看文件最后修改时间判断变没变另一对是基于内容的请求头里的If-None-Match对应响应头里的ETag服务器根据文件内容算出一个唯一标识内容变了标识就变。我强烈建议所有静态资源优先用ETag而不是Last-Modified因为时间戳判断有两个致命问题一是有些服务器返回的时间精度只到秒同一秒内改了文件判断不出来二是文件内容没变但时间变了会引发无谓的重新下载。ETag是对内容做哈希准确度高得多。打个比方强缓存就像你办了张年卡一年内进游乐园直接刷脸闸机都不带响的协商缓存就像每次进园都要给保安看一眼你的门票上的防伪码保安拿机器扫一下真的就直接放行假的他才让你重新买票。一个是“完全信任”一个是“验证信任”。2.3 三级缓存位置从内存到硬盘再到网络除了强缓存和协商缓存浏览器本身还维护着多个层次的内容存储。我在DevTools的Network面板里经常看到资源来源标注为memory cache或disk cache很多人不知道这俩有什么区别。memory cache就是内存缓存读取速度最快几乎不消耗磁盘IO但它的生命周期很短标签页关了、浏览器进程重启了内存缓存就没了。通常JS、CSS这类解析过的资源更容易进内存缓存因为浏览器觉得它们随时可能被再次用到。disk cache是硬盘缓存容量大、持久性强但读取速度比内存慢一个数量级。值得注意的是缓存的存放位置优先顺序大致是这样的先看内存缓存再看硬盘缓存最后才是走网络请求。所以你在Network面板看到的资源可能40%以上都被这两个层级拦截了。这也就是为什么我常跟测试同学说验证一个页面性能一定要开隐身窗口或者勾选Disable cache否则测的全程都是缓存命中数值根本没参考价值。3. 缓存不是万能药什么该缓存、什么不该缓存我见过太多团队上线上出事故之后二话不说把Cache-Control全删了结果性能反而更差。缓存策略不是一个“开了就完事”的开关而是一套需要按资源类型精细化设计的规则。3.1 静态资源怎么配才安全静态资源——JS、CSS、图片、字体——是缓存收益最大的对象但前提是文件名必须带指纹。我说的指纹就是构建工具生成的那串哈希比如app.a3f9d2.js。这类资源的特点是内容变了文件名就变文件名不变内容一定没变。对这类资源我的标准配置是Cache-Control: max-age31536000, immutable。immutable是告诉浏览器这个资源终生不变连协商缓存都不用发。为什么敢这么配因为文件名带指纹之后内容一旦更新构建产物会生成新的文件名用户请求的是新URL旧URL的缓存永远不会被访问到。这样既保证了极致缓存命中又不会出现“代码改了不生效”。这里有个团队新人常犯的错误发版之后发现用户还是旧资源就以为是CDN没刷新其实是因为忘了改文件名或者忘了处理HTML里的引用。文件还是那个文件缓存当然还在。3.2 HTML文件反其道而行之和静态资源的“长期缓存”相反HTML文件我建议采用Cache-Control: no-cache。注意这不是“不缓存”而是“每次使用前先验证一下”。也就是说浏览器每次都会发起协商缓存请求但绝大多数情况下服务器返回304耗一次网络往返保证拿到的是最新HTML又不至于重新下载整个页面。为什么HTML要这么特殊因为HTML是整个应用的“入口清单”里面引用了所有JS、CSS的URL。如果HTML被强缓存了用户拿着旧HTML就永远引不到新版本的JS和CSS哪怕你的静态资源已经更新到天荒地老。这个搭配方案是我在实践中验证过无数次的组合HTMLno-cache保证入口文件始终新鲜。带指纹的JS/CSSmax-age31536000, immutable享受永久缓存。图片等媒体资源max-age31536000不带immutable也行反正几乎没有变更场景。3.3 动态接口缓存的灰色地带动态接口能不能缓存能但要分场景。如果是用户维度的个性化数据——比如购物车列表、订单状态——我绝不建议加HTTP缓存因为每个人的内容都不一样任何一个用户的数据变了其他用户的缓存也没法精准失效。这种情况下更合适的是用前端业务层缓存比如React Query、Vue Query这类数据请求库可以设置staleTime在一段时间内复用同一份数据避免反复请求同时又能手动失效。如果是非个性化、全用户一致的数据比如配置项、版本号、公告内容那就可以大胆设置Cache-Control: max-age60甚至更久。实际项目中我还会配合CDN层的缓存策略在源站和边缘节点之间做分级缓存这样即便源站压力再大CDN边缘节点也能直接兜住大部分请求。4. 实操中的配置与验证方法缓存机制的原理并不难真正难的是把配置落到服务器、CDN和前端代码的各个角落。这一节我分享一套可以直接复用的配置方案和验证流程。4.1 Nginx与CDN层的缓存配置模板如果你用的是Nginx作为Web服务器静态资源的缓存配置可以参考我这里的一套写法location /static/ { expires 1y; add_header Cache-Control public, max-age31536000, immutable; access_log off; } location / { add_header Cache-Control no-cache; expires -1; try_files $uri $uri/ /index.html; }第一段把所有/static/路径下的资源设置为一年强缓存加immutable第二段给HTML设置no-cache保证每次都要协商验证。这套配置我已经在多条业务线里跑过没有再出现“发版用户看不到新功能”的投诉。如果你用了CDN还需要注意CDN节点本身也有缓存。源站的Cache-Control默认会被CDN透传但很多CDN厂商支持在控制台单独配置节点缓存策略。我一般会做两层源站给HTML设no-cache但CDN层对HTML节点设一个很短的缓存比如60秒这样既保证用户拿到新鲜内容又能减轻源站带宽压力。这个60秒的窗口会带来最多一分钟的发布延迟业务可接受但性能提升非常明显。4.2 用DevTools精确判断命中情况配置写完之后开发阶段我建议每一位前端同学都养成打开DevTools看Network面板的习惯重点看两列Size和Time。当资源显示为(from memory cache)或(from disk cache)时说明命中了强缓存没有任何网络请求Size列会直接标出来Time几乎为0。当资源显示304 Not Modified时说明走了协商缓存服务器确认资源未变化传输体积很小但仍有一次网络往返。这两者的区别非常大我之前带团队的时候要求大家只要看到第二次刷新页面还有大量200请求就要立刻排查缓存配置是不是被谁给改了。另外DevTools的Application面板里可以直接看到每一类存储的占用情况包括Cache StorageService Worker用的缓存和本地缓存的明细。排查问题的时候可以直接在面板里找到对应的缓存条目右键删除避免整个站点缓存被清空影响其他同事的联调。4.3 Service Worker把缓存主动权握在自己手中HTTP缓存能做到这个程度按理说已经很好了但它有个天然局限控制权在浏览器和服务器手里前端代码做不了精细的拦截。这时候就需要Service Worker登场了。Service Worker本质上是浏览器和网络之间的一个“代理脚本”它可以在fetch事件里完全接管资源请求逻辑。我在做PWA和弱网优化时会在Service Worker里实现“先缓存后网络”的策略self.addEventListener(fetch, (event) { event.respondWith( caches.match(event.request).then((cached) { if (cached) { return cached; } return fetch(event.request).then((response) { const clone response.clone(); caches.open(my-cache-v1).then((cache) { cache.put(event.request, clone); }); return response; }); }) ); });这个例子虽然简单但非常实用。弱网环境下命中缓存的资源几乎秒开不依赖服务器响应。需要注意的是Service Worker缓存的版本管理很容易被忽略上线新版本时一定要先caches.delete旧缓存否则你的SW会把旧资源一直喂给用户那可比HTTP缓存事故难排查多了。5. 加载性能的进阶玩法预加载与优先级调度缓存策略解决的是“重复加载”的问题而“首次加载”的快慢还需要另外一套手段来优化。这里我分享几个在项目中实测有效的进阶技巧。5.1 提前告诉浏览器预加载与预连接预加载的核心思想是把决策提前。正常情况下浏览器要解析到link或script标签才知道去加载哪些资源这是串行且被动的。使用link relpreload可以主动告诉浏览器这个资源很重要现在就下载别等我解析到。link relpreload href/assets/home-hero.woff2 asfont typefont/woff2 crossorigin比如首页有个全屏Banner图而且用到了自定义字体正常流程要等CSS解析完才知道有字体要加载但通过preload字体请求可以提前几百毫秒发出首屏文字渲染就不容易出现FOUT无样式文字闪烁。preconnect则是提前建立连接。它告诉浏览器这个域名你马上就可能要发请求先把DNS、TCP、TLS握手做完。对于跨域CDN资源非常有效。5.2 动态资源的懒加载与on-demand加载跟“提前”相反的思路是“延后”。对于首屏不可见的内容——比如长列表下方的图片、折叠区里的组件我建议全部走懒加载。现代浏览器原生支持img loadinglazy这个API一开浏览器会自动判断图片是否进入视口再决定是否下载。但它的坑在于首屏低于视口高度一半的图片可能会被提前加载精度不如JavaScript方案高。如果追求精准控制可以继续用IntersectionObserverconst observer new IntersectionObserver((entries) { entries.forEach((entry) { if (entry.isIntersecting) { const img entry.target; img.src img.dataset.src; observer.unobserve(img); } }); }); observer.observe(lazyImage);代码本身没什么高深的但工程上要注意懒加载不能用在首屏关键图上否则首屏图片会晚一个帧周期才会出现反而影响LCP指标。5.3 合理的并发策略浏览器对同一域名的并发连接数是有限制的HTTP/1.1下一般是6个。如果你的页面几十个资源全部堆在同一个域名下后面的只能排队等着。这就是为什么大厂普遍采用CDN域名和主站域名分离——把静态资源放在static.example.com接口请求放在api.example.com等于把排队通道翻了一倍。但HTTP/2普及之后多域名反而可能有性能损耗因为连接的多路复用被域名拆散了。现在的最佳实践是单域名 HTTP/2配合资源合并。我在新项目里已经全面切到了这种模式连接数不再是瓶颈真正影响时间的是每个请求本身的传输与解析。6. 常见问题与排查经验实录最后分享几个我在真实项目里碰到过的问题和排查过程。缓存机制的事故有个共同特点不是立即爆发而是悄悄累积等发现的时候已经有很多用户中招了。6.1 改完代码用户看不到更新这个问题出现频率最高。排查流程我基本固定成三板斧第一步用DevTools的Network面板看HTML请求的响应头里Cache-Control是什么。如果是max-age且数值很大那就说明HTML被强缓存了直接去改Nginx或服务端配置。第二步看JS/CSS文件是不是带指纹。没带指纹的话即使Cache-Control配置没问题发版后文件名不变旧缓存一样生效。解决方式是给构建配置加上contenthash。第三步检查Service Worker。现在很多项目都注册了SW旧的SW里缓存了旧版HTML即使服务端更新了SW也会优先返回自己的缓存。在Application面板里看Service Workers标签点击Unregister测试一下通常就能定位。6.2 请求都200但Size显示disk cache有朋友问过为什么Network里都是200状态码但资源还是走了缓存这是因为浏览器在某种情况下会拉长max-age的判定。比如用户点击前进后退按钮、页面被bfcache往返缓存恢复时浏览器可能直接用缓存而不发请求状态码就是200但来源标记为缓存。这种情况不是事故不需要紧张。如果你的页面从列表页跳到详情页再返回列表页时列表数据是旧的那说明数据级别的缓存策略有问题应该考虑用pageshow事件重新拉取关键接口。6.3 304请求太多拖慢整体加载协商缓存虽然比全量下载好但304也是要发一次请求的如果页面有100个静态资源都走协商缓存那同样会产生100个请求只是响应体变小了而已。我要指出强缓存才是零请求协商缓存只是“轻请求”。要减少304的数量唯一有效的方案就是给所有静态资源文件名加指纹并设置足够长的max-age让浏览器完全进入强缓存状态。不要心疼那点CDN流量缓存命中率提升之后源站带宽成本下降会远比这多。写到这里我把资源加载的链路和缓存机制的落地方案、排查方法都过了一遍。我个人体会最深的一点是缓存机制不是“配完就一劳永逸”的东西它需要根据业务形态、发布频率、用户使用场景持续调整。比如我们曾经为了追求极致的强缓存给所有API都加了很长的max-age结果运营改个活动配置用户端整整两天看不到变化最后灰溜溜地又把缓存时间缩短。缓存的设计本质上是在“性能”和“新鲜度”之间做权衡没有银弹只有理解了原理之后才能针对每一种资源做出最合理的决策。这套方法我用了很多年也带着团队踩了不少坑才总结出来希望你看完之后能少走几步弯路。