html缓存命中率无法被javascript直接读取，但可通过network面板的status/size字段、performance api的transfersize、x-cache响应头及服务端日志等组合信号精准反推缓存层级与失效原因。

HTML缓存命中率无法用 JavaScript 直接读取，但能通过组合可观测信号精准反推——关键不是“有没有缓存”，而是“哪一层命中了、为什么没命中、是否被绕过”。

看 Network 面板里的 Status 和 Size 字段

这是最直观、无需代码改动的验证方式。打开 Chrome DevTools → Network，刷新页面后重点观察 index.html 和核心静态资源（如 main.a1b2c3.js）：

• Status 显示 (from cache) 或 (from disk cache)：说明浏览器本地强缓存生效，没发任何网络请求
• Status 是 304 且 TTFB ：协商缓存命中，服务器只返回响应头，不传 body
• Status 是 200 且 Size 列显示具体字节数（比如 12.4 KB）：强缓存和协商缓存都失效，完整下载 HTML
• 注意 X-Cache 或 X-CDN-Cache 响应头：如值为 HIT，说明 CDN 层也命中了，属于叠加命中

用 Performance API 捕获 transferSize 和 encodedBodySize

window.performance.getEntriesByType("navigation") 返回的导航记录里，这两个字段是判断缓存行为的关键证据：

Html2md

使用 Readability + Turndown 将 HTML 页面转换为干净的、Agent 友好的 Markdown。去除导航栏、广告、页脚、Cookie 横幅、社交按钮等干扰元素。支持 URL...

下载

• transferSize === 0：大概率命中本地强缓存（注意：部分浏览器在 304 场景下也可能为 0，需结合 responseStatus 判断）
• encodedBodySize 远小于首次加载值，且 transferSize 很小：说明复用了压缩后的缓存副本
• fetchStart → responseStart 时间差显著缩短（比如从 200ms 缩到 5ms）：典型缓存生效表现，尤其适用于自动化监控上报

检查 Cache-Control 和 ETag 配置是否自相矛盾

很多“缓存没生效”问题其实出在服务端配置冲突上，而不是前端代码：

• Cache-Control: no-cache 被误用于 HTML：它不禁止缓存，但强制每次发条件请求，TTFB 升高、请求数翻倍
• max-age=0 或硬编码 no-store：等于主动关闭缓存，浏览器连本地存储都不做
• 缺少 ETag 或 Last-Modified：协商缓存失效后，浏览器只能重新下载整个 HTML，比没缓存还糟
• 构建产物未带哈希（如始终输出 index.html）：即使设了 immutable，内容一变就导致旧缓存失效，命中率断崖下跌

关联服务端日志与前端 timing 数据

单看前端指标容易误判。比如前端 transferSize === 0，但用户仍感觉卡顿——问题可能不在缓存，而在 JS 执行或渲染阶段。

• 在 Nginx 日志中开启 $upstream_http_cache_status，记录每次 HTML 请求的真实缓存状态（HIT/MISS/EXPIRED）
• 把该状态和服务端时间戳，和前端上报的 domContentLoadedEventEnd、loadEventEnd 关联分析
• 发现服务端标记 HIT 但前端 load 时间很长：说明瓶颈在客户端，不是缓存没起作用

真正影响命中率的，往往不是缓存开关开没开，而是 HTML 字节流是否稳定、Cache-Control 是否和部署方式匹配、以及有没有在无意中触发强制刷新（比如用户按 Ctrl+F5）——这些细节在压测和灰度阶段最容易被忽略。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！