网站加载速度怎样排除缓存造成的假象：先分清浏览器、CDN与服务器三层
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b883031e365d.html
📄
网站加载速度怎样排除缓存造成的假象：先分清浏览器、CDN与服务器三层
排除缓存假象的核心做法是：让同一份资源分别经过“清空浏览器缓存”“绕过CDN缓存”“直连源站”三种路径加载，再对比耗时与响应头。如果三次结果差异很大，你之前看到的“变快”或“变慢”很可能来自缓存，而不是网站本身的真实加载速度。第一次接触这个问题，起点是先确认你测的是哪一层缓存，而不是急着改代码或换服务器。
先分清三层缓存各自制造的假象
网站加载速度的测量结果会被三类缓存影响，表现完全不同：
- 浏览器缓存：第二次访问时图片、CSS、JS 直接从本地读取，耗时骤降。你看到的“快”只是自己电脑的快。
- CDN 或反向代理缓存：边缘节点返回已存副本，源站根本没被请求。你测到的可能是节点到你的距离，而不是源站性能。
- 服务器端缓存：页面缓存、对象缓存让动态页面变成静态输出，数据库压力被隐藏。清掉后真实耗时才会暴露。
判断依据是响应头，不是感觉。重点看 Cache-Control、Age、X-Cache、CF-Cache-Status 这类字段：Age 大于 0 说明命中了共享缓存；出现 HIT 说明 CDN 返回了副本；只有 MISS 或没有缓存标记时，请求才真正落到源站。
准备：固定测试条件，避免混入其他变量
在动手之前，先把变量控制住，否则清缓存前后对比也不可信：
- 用同一台设备、同一个网络、同一个浏览器配置测试，不要一次用手机热点、一次用公司宽带。
- 关闭浏览器扩展，尤其是广告拦截和代理类插件，它们会改变请求路径。
- 准备一个无痕窗口作为对照，但要知道无痕只隔离本地缓存，不影响 CDN 和服务器缓存。
- 记录测试时间，CDN 节点和网络状态会随时间波动。
这一步的产出是一份可复现的基线：同一个 URL、同一组条件、连续测三次，记录每次的总耗时和关键响应头。
实施：最关键的一步是绕过缓存直连源站
本题最关键的动作，是让请求跳过浏览器和 CDN，直接打到源站。常用做法有：
- 在 URL 后加一个唯一查询参数，例如
?nocache=20240101a，用于绕过部分 CDN 和代理的缓存键。注意：它只对把查询串纳入缓存键的配置有效，不是万能。 - 用开发者工具的“禁用缓存”选项，只影响浏览器层，不能绕过 CDN。
- 直接请求源站 IP 并带上
Host头，可以完全跳过 CDN，但需要你确认源站接受这种方式，且证书配置允许。 - 在 CDN 控制台执行缓存刷新，然后立即重测，观察耗时是否回到未缓存水平。
适用条件是：你能确认 CDN 与源站的分层关系。如果站点没有使用 CDN，就只需要处理浏览器缓存和服务器端缓存两层。判断结果是：直连源站明显慢于走 CDN 时，说明你之前看到的快来自边缘缓存；直连与走 CDN 接近，说明缓存对速度贡献有限，瓶颈在别处。
验证：用对比而不是单次数字下结论
把三次测量放在一起看，而不是只看某一次：
- 首次访问（本地无缓存、CDN 未命中）：反映最接近真实的完整加载路径。
- 二次访问（本地命中）：反映回访用户的体验。
- 强制刷新或清缓存后访问：验证缓存是否真的在起作用。
如果首次和二次差距极大，说明静态资源缓存策略生效，这是正常优化，不是假象；如果清缓存前后几乎没差别，说明你之前看到的耗时本来就不依赖缓存。需要警惕的是另一种情况：测试时命中了 CDN，误以为源站很快，实际首次访问用户面对的是慢得多的源站响应。
维护：把缓存检查变成例行动作
缓存配置会随发布、改版、换 CDN 而变化，建议在每次上线后做一次固定检查：
- 抽查首页和几个关键静态资源的响应头，确认缓存策略与预期一致。
- 发布新版本后确认文件名或版本参数已更新，避免用户拿到旧缓存。
- 定期在无缓存条件下测一次首屏耗时，作为真实性能的参照。
下一步建议：选一个你正在关注的页面，按上面的准备条件连续测三次，记录响应头里的缓存标记和每次耗时，先判断你看到的数字属于哪一层缓存的结果，再决定是否调整缓存策略或优化源站。
