要排除缓存造成的假象,最直接的做法是让浏览器、中间层和源站都不返回旧副本:在开发者工具中勾选禁用缓存,同时用带随机查询参数的URL发起请求,再用无痕窗口或新会话复测。如果两次结果差距很大,说明你之前看到的“快”或“慢”很可能来自缓存,而不是页面加载速度的真实表现。
页面加载速度的测量结果受多层缓存影响,常见的有:浏览器本地缓存、Service Worker缓存、CDN边缘缓存、反向代理缓存、应用层对象缓存和数据库查询缓存。它们的作用都是复用旧结果,因此会让复测结果偏离首次访问或冷启动时的真实开销。
判断依据是响应头。查看 Cache-Control、Age、X-Cache、CF-Cache-Status 等字段,若出现命中标识或较大的 Age,说明当前结果来自缓存副本。
最关键的一步是构造一个缓存无法命中的请求。具体操作如下:
?nocache=20240601a,避免CDN和代理按同一键命中。适用条件是你能控制测试URL且页面允许带参数访问。若页面路由不接受额外参数,可改用清空站点数据后重新加载,或在服务端临时关闭CDN缓存进行对比。判断结果是:禁用缓存后指标明显变差,说明此前数据被缓存美化;若几乎不变,则缓存不是主要变量。
把同一页面的“缓存命中”和“缓存未命中”两组结果并排比较。重点看三项:TTFB差值、HTML文档大小是否一致、静态资源是否返回304或200。如果未命中时TTFB显著升高,瓶颈通常在源站生成或数据库查询;如果只是资源下载变慢,问题更可能在传输链路或资源体积。
还要注意区分“可能原因”和“已经定位的原因”。例如TTFB高可能有多个解释:源站计算慢、回源链路长、DNS解析慢或连接复用不足。只有结合服务端日志、数据库慢查询记录和CDN回源日志,才能确认是哪一项。
缓存策略会随发布、配置和流量变化而改变,因此需要定期复测。建议在每次上线后、调整CDN规则后、以及收到速度投诉时,各执行一次禁用缓存的冷启动测试,并保存响应头和指标截图作为对照基线。
日常检查项可以包括:关键页面的 Cache-Control 是否被误设为长时间缓存HTML;CDN是否缓存了带用户信息的接口;Service Worker版本是否及时更新;源站日志中回源比例是否异常下降。把这些项目纳入发布清单,可以避免缓存再次掩盖页面加载速度的真实问题。
下一步,选一个你怀疑被缓存美化的页面,按上面的步骤做一次禁用缓存与带随机参数的冷启动复测,并把命中与未命中的TTFB和资源加载明细记录下来,再决定优化方向。