我用7天把91网的体验拆开：最关键的居然是缓存管理（不服你来试）

黑料今日 2026年02月25日 12:25 145 V5IfhMOK8g

标题是挑衅的，但结论确实直接：把缓存管理做好，用户的感受提升比任何单点性能优化都更明显。花7天把站点拆开、测量、改造、复测，过程清晰、可复制——下面把我做的事、遇到的问题和解决方案一股脑儿给你，照着做就能看到差距。不服？你可以按同样方法来验证。

为什么缓存管理比看上去更“关键”

首访优化能提升感知性能，但用户真正常有的是回访、跳转、频繁触发的接口请求。良好的缓存策略直接决定重复访问的响应速度和体验稳定性。
错误的缓存会导致刷新后看到旧数据、登录态异常、页面闪烁或频繁请求后端，放大服务器负载并影响并发体验。
浏览器缓存、CDN缓存、Service Worker 缓存、API 缓存、应用内缓存（localStorage/IndexedDB）等层级一起工作，要协调才能发挥最大效益。

我7天的行动纲要（可直接复刻） Day 0（准备）

建立基线：用 Lighthouse、WebPageTest、以及 Chrome DevTools 的 Network 面板记录首屏时间、FCP、LCP、TTFB、总请求数和体积。确定关键页面与关键请求（首页、登录、详情页、静态资源、热门 API）。
把所有资源列出来：静态资源（js/css/img）、接口（JSON、HTML）、第三方资源（CDN、analytics）和动态页面。

Day 1：检查和理解现状

检查 HTTP 响应头：curl -I https://91.example.com/path
重点看 Cache-Control、Expires、ETag、Last-Modified、Vary、Set-Cookie。
用 Chrome DevTools Network 列出哪些请求每次都会 200（未命中缓存），哪些返回 304（协商缓存），哪些返回 200 且带 Cache-Control: max-age。

常用命令： curl -I https://91.example.com/static/app.js curl -I -H "Cache-Control: no-cache" https://91.example.com/api/data

Day 2：为静态资源制定策略

静态资源（js/css/img/font）推荐采用强缓存 + 文件指纹（hashing）策略。也就是 nginx/ CDN 设置 Cache-Control: public, max-age=31536000, immutable，同时通过构建工具把文件名包含 hash（app.f3a1c2.js）。
HTML 页面采用短缓存或协商缓存：Cache-Control: no-cache 或 max-age=0, must-revalidate，配合 ETag/Last-Modified，保证用户能及时拿到最新页面。

示例 nginx 配置（只需把路径替换为你自己的）： location ~* .(?:css|js|jpg|jpeg|png|gif|svg|woff2?)$ { addheader Cache-Control "public, max-age=31536000, immutable"; } location / { addheader Cache-Control "no-cache, must-revalidate"; }

Day 3：API 与动态数据的缓存策略

区分可缓存数据与必须实时的数据。像排行榜、推荐、商品详情（非库存）等可以短期缓存（s-maxage 或 max-age 60-300）。库存、订单状态等应走实时或采用更复杂的回源策略。
使用 Cache-Control 与 CDN 的边缘缓存（s-maxage）来减轻后端压力。配合 Cache-Tag 或路径版本化实现细粒度失效。
对于用户特定的数据，避免缓存到公共 CDN 边缘；对匿名聚合数据才放边缘缓存。

示例 Header： Cache-Control: public, max-age=60, s-maxage=300

Day 4：Service Worker 与 Cache API（离线与加速）

使用 Service Worker 在客户端做“第一次加载后”的快速响应：把核心 shell（HTML/CSS/JS）、常用图片和常用接口缓存到 Cache Storage。对 API 可以使用 network-first + fallback-to-cache、或 stale-while-revalidate 策略。
注意 Service Worker 的缓存更新逻辑和版本控制，避免用户长期卡在旧版本。

简化版 Service Worker 缓存策略（伪代码）： self.addEventListener('fetch', event => { if (isApiRequest(event.request)) { event.respondWith(networkFirst(event.request)); } else { event.respondWith(cacheFirst(event.request)); } });

Day 5：缓存失效与发布流程

文件名指纹化 + 自动化构建（webpack/rollup/parcel 等）来保证静态资源可以长期缓存且能安全更新。
对需要强制更新的资源，使用 HTML 中的版本号或 manifest 控制。发布流程里在 CDN 层做回退与预热（pre-warm）以减少首次回源压力。
实现可控的缓存清理（例如通过 Cache-Control + Cache-Tag 或在 CDN 上进行按路径清除）。

Day 6：观测与回放测试

重测 Lighthouse、WebPageTest，关注回访体验（repeat view）和首访体验的差别。检查 TTFB、LCP、Total Blocking Time。
用真实用户监测（RUM）采集首屏时间、可交互时间。对比改造前后，尤其看重回访的首屏耗时降低多少、接口平均响应时间与失败率是否下降。

Day 7：梳理文档与逐步放量