接入CDN后，刷新几次首页变快，并不足以证明所有用户体验都改善了。浏览器可能直接用了本地缓存，测试节点可能恰好离某个边缘节点很近，也可能只看到了静态文件的变化。可靠的测试要先定义样本、条件和观察指标，再比较相同条件下的结果。
固定测试对象与环境
建议选择一张常用图片、一个脚本文件、一个公开HTML页面和一个动态接口。记录URL、文件版本、请求方法、登录状态、地区、网络类型与测试时间。接入前后的页面版本和内容大小应尽量一致，否则图片压缩带来的收益容易被全部归给CDN。
对照环境可以使用经过授权的测试域名或上线前留存记录，不要为了测速临时暴露受保护的源站。生产环境只做低频、可控的检查，容量压测应另行安排。
明确“冷”和“热”指哪一层
| 状态 | 如何描述 | 容易产生的误判 |
|---|---|---|
| 浏览器缓存 | 本次是否从内存或磁盘取资源 | 本地秒开被当成边缘响应快 |
| 边缘冷缓存 | 对应节点与缓存键尚无可复用内容 | 一次MISS代表全部地区都冷 |
| 边缘热缓存 | 同一缓存键已命中有效副本 | 其他地区也一定同样命中 |
| 连接复用 | 是否已有DNS、TCP或TLS状态 | 复用连接与首次访问混合比较 |
浏览器开发者工具里的“禁用缓存”不能保证CDN边缘也处于冷状态。也不要不断追加随机参数模拟冷缓存：参数是否进入缓存键取决于配置，还可能制造大量无意义副本。优先用平台提供的测试方法，明确影响范围后再刷新指定测试对象。
同时记录耗时、错误与样本量
至少记录TTFB、总下载时间、状态码和边缘缓存状态。web.dev对TTFB的说明指出，导航场景中它涵盖连接建立及等待首字节等阶段，因此不能直接等同于源站程序执行时间。页面体验还要结合LCP等实际呈现指标。
平均值容易掩盖慢请求，可增加中位数和p95。一个演示性的计算办法是将100个有效耗时升序排列，以第95个作为最近秩法的p95；这只是统计方法示例，不是本站测速结果。必须同时保留超时与失败比例，不能把失败样本删掉后宣布“速度提升”。样本太少时，p95也不稳定，应标明次数与统计窗口。
怎样形成可以复测的结论
- 在主要用户地区和不同访问时段重复相同测试，分别保存原始记录。
- 将静态命中、静态未命中与动态接口分组，不把三者平均到一个数字里。
- 查看回源流量与错误率，判断加速是否以更多源站压力或失败为代价。
- 报告改善发生在哪些条件，同时列出未改善的地区、接口及下一步排查点。
如果测速过程出现旧内容，先排查浏览器、WordPress与CDN的缓存层级。一份能复现条件的测试记录，比“全网都快了”的描述更有决策价值。
作者：lgd。资料核对：2026-10-08。本文采用AI辅助整理；示例与配图用于说明方法，不代表本站实测数据。具体功能和限制请以所用产品的当前文档及配置为准。
