刷新后页面更快不一定是网络改善：缓存新鲜度、验证与响应年龄怎样核对

第一次打开页面需要等待，按下普通刷新后却几乎立刻完成。这个变化看起来像网络恢复，实际可能只是浏览器没有再次传输相同正文。若第二轮直接重用缓存，拿它与首次加载比较，就把两种请求路径混在了一起。

刷新后的速度变化只有在缓存状态与验证结果已知时才有意义。新鲜缓存可以不联系源站，过期缓存可能只发送条件请求确认旧内容仍可使用；两种情况都能比完整响应更快，却都不能证明线路持续改善。

新鲜缓存为什么可以绕过源站

HTTP缓存保存响应后，会判断它是否适合满足下一次请求。RFC 9111要求目标URI、方法及Vary指定的请求字段相符，还要确认响应仍然新鲜、获准使用陈旧内容，或已经成功验证。

所谓新鲜，是当前响应年龄没有超过新鲜寿命。源站通常以max-age或Expires给出期限；在允许的条件下，缓存也可能计算启发式期限。只要匹配条件成立且响应仍新鲜，缓存就能直接重用旧响应，不必为这次刷新联系源站。

这正是普通刷新突然变快的常见边界：用户看到的是本机很快取得已有内容，而不是一次更快的远端传输。页面显示正常可以说明缓存副本可用，却不能据此断言源站当时也以相同速度响应。

RFC 9111还区分服务单一用户的私有缓存与服务多个用户的共享缓存。浏览器、设备和中间路径可能保存不同副本，因此另一台设备的同一URL不一定走相同路线。

Age不是文件日期，也不是等待时间

Age表示响应从源站生成或成功验证之后经过的估计秒数。它帮助缓存计算当前年龄，但不是资源发布日，也不是用户这次刷新等待了多久。

Age较大不等于这次请求较慢。一个仍在新鲜期内的较老响应，可能直接从缓存返回；一个Age很小的响应，也可能来自刚刚完成的网络验证。必须把Age与Cache-Control、Expires、Date及本次状态放在一起解释。

同一URL还可能按Vary指定的请求字段保存多个响应变体。语言、内容编码或其他协商字段不同，缓存就不能把一个版本无条件交给另一种请求。刷新前后若匹配了不同变体，体积和耗时变化也不能写成单纯的线路变化。

过期响应怎样完成验证

缓存超过新鲜寿命后，不代表一定重传全部正文。客户端可以带上ETag或修改时间发出条件请求。源站若确认资源未改变，通常返回304 Not Modified；浏览器更新缓存元数据，并继续使用先前保存的正文。

304仍然发生网络往返，但省去了完整正文传输。因此刷新可以比首次加载快很多。这个结果证明旧响应通过了本次验证，不证明之后每一次请求都会同样快，更不能把它扩大成线路已经恢复。

源站若返回完整响应，则表示旧副本不适合继续沿用，或者这次请求没有满足验证条件。比较200与304时，必须同时观察正文体积与验证器，不能只看总耗时。

强制刷新会改变通常的缓存选择，因此适合用来确认缓存是否影响眼前现象，却不适合作为长期性能样本。反复强制刷新制造的是另一类请求负载，不能与普通浏览行为混为同一组数据。

三个大小字段怎样帮助辨认路径

W3C Resource Timing分别提供transferSize、encodedBodySize和decodedBodySize。transferSize描述本次资源条目记录的传输规模；encodedBodySize描述内容编码后的正文体积；decodedBodySize则是解码后正文体积。三个字段回答的问题不同。

草案规定，本地缓存模式的transferSize返回零，已验证缓存模式返回固定的小值，普通传输则以编码正文大小加固定开销表示。固定开销不是实际HTTP头总量，因此这些字段适合辨认缓存路径与正文是否重传，不适合充当精确流量账单。

若内容使用gzip等编码，encodedBodySize通常小于decodedBodySize。刷新前后协商到不同内容编码时，即使页面意思相同，数值也可能不同。比较时不能任选一个字段称作下载文件大小。

看到transferSize为零仍不能立即宣布缓存命中。跨来源限制也可能让大小字段归零；资料不可见与没有网络传输是两种不同结论。记录中应把零值标为已确认本地缓存、受跨来源限制或原因未知。

Service Worker还能改变观察范围

页面若由Service Worker拦截请求，它可以返回自己的缓存内容、合成响应，也可以在内部另外访问网络。Resource Timing条目可能只呈现页面客户端与Worker之间的交互，并不完整显示Worker内部活动。

因此极短的responseEnd不能自动改写成源站即时响应。还要查看workerStart、浏览器开发者工具或服务端记录，确认这次内容究竟来自Worker缓存还是远端请求。规范也允许浏览器为了隐私施加更严格的字段限制。

留下两轮可复查记录

固定同一URL，分别保存首次加载和普通刷新两轮数据。每轮记录开始与结束时间、响应状态、transferSize、encodedBodySize、decodedBodySize、Age。ETag或Last-Modified、是否由Service Worker处理，以及字段是否受跨来源限制。

首次加载回答完整取得资源时发生了什么；普通刷新回答缓存怎样满足下一次请求。若第二轮直接使用新鲜缓存，结论停在“没有为正文联系源站”；若得到304，结论停在“通过网络验证后沿用旧正文”；若得到200和完整体积，才说明正文重新传输。

若目的是判断内容一致，还需要另查文件摘要或发布方提供的完整性资料。这些计时与缓存字段能够解释本次请求路径，却不能证明客户端文件安全、完整或属于当前正式版本。

结论边界很清楚：刷新变快可以由新鲜缓存、条件验证、Service Worker或字段可见性造成。只有把两轮请求放在同一资源、同一操作和相同观察权限下，耗时变化才有可解释性；即使如此，它仍不是线路长期改善的证据。

缓存新鲜度、验证与响应年龄参考以下标准：

• World Wide Web Consortium，Resource Timing，2026年4月20日。
• RFC Editor / IETF，RFC 9111: HTTP Caching，2022年6月。

资料来源

• World Wide Web Consortium：《Resource Timing》，发布或更新于 2026-04-20
• RFC Editor / IETF：《RFC 9111: HTTP Caching》，发布或更新于 2022-06-01