SWR是彻底取消等待的缓存策略:首次渲染用缓存,后台静默更新;需服务端设置Cache-Control头,仅Chrome≥75/Firefox≥115原生支持;Service Worker手动实现更通用,框架层SWR库提供staleTime等精细控制。
Stale-While-Revalidate(SWR)不是“更快地等网络”,而是彻底取消等待——页面首次渲染用缓存,用户开始滚动时新数据已在后台就位。它把“加载”这个概念从用户感知中移除,是渐进式网页加载(PWA)真正落地的关键一环。
服务端必须正确声明 SWR 响应头
HTML 文件本身无法启用 SWR,
meta 标签完全无效
。必须由后端在 HTTP 响应头中明确设置:
Cache-Control: max-age=30, stale-while-revalidate=300
—— 表示资源新鲜期 30 秒,过期后 5 分钟内仍可直接返回缓存并后台验证
仅对
(如首页导航)或
(如 API 请求)生效;
、
等资源不支持
当前仅 Chrome ≥75 和 Firefox ≥115 原生支持;Safari 和 Edge(即使基于 Chromium)多数版本未启用该行为
Service Worker 中手动实现更可控的 SWR
绕过浏览器兼容限制,用 Cache API 自主实现 SWR 是更通用、更可靠的方式,尤其适合 PWA 场景:
在
事件中,先调用
,若命中立即
无论是否命中,都同步发起
在
中:
✓ 先
(避免 body 被多次读取报错)
✓ 一份写入缓存:
✗ 不要用该 response 直接 return 给
,否则阻塞首屏
对首页请求,建议结合
导航预加载(Navigation Preload)
,让 SWR 在页面跳转瞬间就启动后台更新
前端框架层的 SWR 实践(以 Vue / React 为例)
当数据请求发生在组件内(而非 HTML 文档加载),框架级 SWR 库(如 swrv、TanStack Query)能提供更细粒度控制:
staleTime
控制“多旧的数据还能直接展示”:设为
(1 分钟),用户刷新页面立刻看到上一次内容
cacheTime
控制“不用的数据保留多久”:设为
(10 分钟),避免内存泄漏
首次加载走网络 + 缓存;后续访问自动触发“返回缓存 → 后台 revalidate → 更新 UI”三步闭环
配合 Suspense 或 loading fallback,整个过程对用户完全无感,连“加载中”提示都可省略
关键细节与常见陷阱
SWR 看似简单,但几个细节决定成败:
响应体只能被读取一次:务必用
分发给缓存和浏览器,否则报
不要在
事件里做耗时逻辑(如 JSON.parse),应在返回前完成处理,保证首字节极快
预缓存首屏关键资源(HTML、核心 JS、字体、首屏图片),让 SWR 有“旧数据”可返,否则退化为 network-first
在
阶段清理旧缓存版本,避免缓存膨胀和策略混乱
destination === 'document''json'fetchcaches.match(event.request)return responseconst fetchPromise = fetch(event.request)fetchPromise.then(response => {...})const cloned = response.clone()cache.put(event.request, cloned)event.respondWith()60 * 100010 * 60 * 1000response.clone()TypeError: Response body is already usedfetchactivate