我用7天把91网的体验拆开：最关键的居然是缓存管理

频道：猫圈热搜榜日期：2026-03-04 00:33:01 浏览：50

引子我用一周时间把91网的用户体验从“还行”推进到“舒服”，过程像解一道拆装题：每一件零件都重要，但最关键的，竟然是缓存管理。下面把我的7天拆测顺序、具体操作和能直接落地的策略写清楚，给做产品或前端优化的朋友参考。

Day 0 — 起点和衡量标准先量化：把目标和指标列清楚，方便对照效果。我的关注点：

首屏可见时间（FCP/LCP）
交互可用时间（TTI）
首次字节时间（TTFB）
总体页面体积和请求数工具：Chrome DevTools、Lighthouse、WebPageTest、Charles/浏览器Network面板、CDN日志

基线数据（示例）

LCP ≈ 4.6s
TTI ≈ 8.2s
页面大小 ≈ 3.5 MB
请求数 ≈ 78

Day 1 — 切片分析，锁定瓶颈把页面拆成三类资源：

可长期缓存（静态资源：指纹化的 JS/CSS/图片）
可短期缓存（页面 HTML、API 响应）
不缓存或必须实时刷新（个性化数据、会话类 API）

发现的问题：

静态资源没有合理设置 Cache-Control，CDN 也未开启边缘长缓存
页面 HTML 的缓存策略混乱，导致频繁回源
客户端缺少统一的缓存策略（没有 Service Worker 或 SW 策略混乱）

Day 2 — 静态资源：指纹 + 长缓存目标：让绝大多数静态资源在浏览器和 CDN 中长期命中，减少请求数和回源。

具体做法：

资源指纹（filename.[contenthash].js）
静态资源（指纹后）设置 Cache-Control: public, max-age=31536000, immutable
在 CDN 层开启边缘缓存（edge cache）并同步 ttl
HTML、API 等设置较短的 max-age 或 no-cache

为什么有效：指纹 + immutable 可以把浏览器缓存时间拉到一年，CDN 边缘缓存减少源站压力，大幅提升命中率和降低延迟。

Day 3 — HTML 和 API 缓存策略：分层与失效重点：HTML 和个性化数据不能像静态资源那样长缓存，采用分层缓存和部分缓存技术。

策略：

页面骨架/模板采用边缘渲染或 SSR + 缓存（短 TTL 或基于标签的缓存失效）
个性化片段通过 JS 异步拉取并单独缓存（localStorage/IndexedDB + SW）
对 API 使用 ETag/Last-Modified 做条件请求，减少传输带宽

示例 header：

HTML: Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=30
API（共通）：Cache-Control: private, max-age=0, must-revalidate 或使用 ETag

Day 4 — 引入 Service Worker：离线友好与运行时缓存把 Service Worker 当作“高级缓存控制器”来用，不是简单为离线而离线。

常用策略：

precache（关键静态资源，在安装阶段缓存）
runtime cache（图片、第三方库使用 cache-first 或 stale-while-revalidate）
network-first 用于需要实时性的 API；cache-first 或 stale-while-revalidate 用于媒体和库文件

示例（伪代码）: // precache self.addEventListener('install', event => { event.waitUntil( caches.open('precache-v1').then(cache => cache.addAll(['/app.css', '/app.js', '/logo.png'])) ); }); // runtime self.addEventListener('fetch', event => { const url = new URL(event.request.url); if (url.origin === location.origin && url.pathname.startsWith('/api/')) { event.respondWith(networkFirst(event.request)); } else { event.respondWith(cacheFirst(event.request)); } });

注意点：