网站测速结果不一致？CDNChart和PageSpeed Insights对照方法

同一个页面放进CDNChart和PageSpeed Insights，可能出现看似矛盾的结果：

• CDNChart显示部分地区总耗时超过3秒，PageSpeed性能得分却有90分；

• CDNChart各地访问都比较快，PageSpeed移动端得分却只有50分；

• PageSpeed实验室数据表现不错，真实用户数据仍显示“需要改进”；

• 网站在国内电信节点很快，PageSpeed测试结果却不断波动。

这些结果不一定是谁测错了。更常见的原因是：两个工具并没有测量同一件事。

CDNChart主要回答“用户从不同地区和运营商访问这个URL时，网络请求是否顺利、被调度到了哪个IP、各阶段花了多长时间”；PageSpeed Insights则更关注“浏览器打开页面后，主要内容多久出现、页面是否跳动、主线程是否阻塞，以及真实Chrome用户获得了怎样的体验”。

CDNChart偏向检查地区、运营商、DNS、CDN节点和HTTP请求链路；PageSpeed偏向检查浏览器渲染、前端资源和用户体验指标。两者应当相互补充，而不是直接比较一个总耗时和一个性能分数。

CDNChart与PageSpeed测量的不是同一层

判断网站测速结果不一致，第一步不是看哪个数字更小，而是确认这个数字代表什么。

例如，CDNChart中的“总耗时”不能直接与PageSpeed中的LCP比较。

总耗时反映测试节点请求被测URL所经历的网络与传输过程；LCP关注浏览器视口内最大内容元素完成渲染的时间。后者还会受到HTML解析、CSS、JavaScript执行、字体、图片优先级和设备性能影响。

同理，PageSpeed的“85分”也不能换算成“网站需要1.5秒打开”。根据Lighthouse性能评分说明，性能分数是多个指标经过评分曲线和权重计算后得到的综合结果，并不是某个请求耗时的直接表达。

PageSpeed报告里其实有两类数据

不少人把PageSpeed页面上的所有数字都当成一次测速结果，这是造成误判的另一个原因。

PageSpeed Insights通常包含两种性质完全不同的数据。

真实用户数据：回答过去一段时间的用户体验

报告顶部可能显示来自Chrome用户体验报告，也就是CrUX的数据。它汇总符合条件的真实Chrome用户访问记录，并使用滚动时间窗口反映历史体验。

按照PageSpeed Insights官方说明，其现场数据通常代表过去28天，并以第75百分位数判断体验质量。它不是你点击“分析”按钮后刚刚从某个地区发起的一次请求。

这意味着，即使今天刚完成CDN迁移，CDNChart已经显示新节点生效，PageSpeed真实用户数据也不会立即全部变好。旧CDN、旧前端版本和迁移前的慢访问仍可能包含在统计窗口内。

还要确认PageSpeed展示的是：

• 当前URL级数据；

• 整个源站级数据；

• 移动设备数据；

• 桌面设备数据。

如果页面样本不足，可能没有URL级现场数据。没有CrUX数据不代表网站无法访问，也不代表性能一定不好，只能说明符合其统计条件的样本不足。

实验室数据：回答当前页面在模拟环境里的表现

PageSpeed下方的性能得分来自Lighthouse实验室测试。它会在受控设备和网络条件下加载页面，生成FCP、LCP、Speed Index、TBT、CLS等指标。

实验室测试更适合定位问题，例如：

• 最大内容元素是不是加载过晚；

• JavaScript是否长时间占用主线程；

• 首屏图片是否过大；

• CSS或字体是否阻塞渲染；

• 页面加载期间是否发生明显位移。

但它只是特定测试环境下的一次或少数几次加载。服务器负载、广告内容、A/B测试、第三方脚本以及网络路由变化，都可能令分数波动。

如果PageSpeed的现场数据和实验室数据互相矛盾，可以结合Google对实验室数据与现场数据差异的解释进行判断：现场数据更适合确认真实用户是否长期受影响，实验室数据更适合复现和调试具体问题。

为什么CDNChart很快，PageSpeed移动端却很慢？

这是最常见的一组结果。

假设CDNChart显示目标地区解析、连接和下载耗时都不高，状态码也正常，说明CDN节点和基础请求链路没有暴露出明显问题。但页面进入浏览器后，仍可能因为以下因素变慢：

• 首屏大图没有压缩或没有合理设置加载优先级；

• JavaScript包体积过大，低性能手机执行缓慢；

• CSS、字体或同步脚本阻塞首次渲染；

• 页面依赖大量第三方广告、统计或客服脚本；

• 首屏内容需要客户端请求API后才能生成；

• 缓存命中了HTML，但图片、字体和脚本没有有效缓存；

• 页面元素加载后改变尺寸，导致CLS升高；

• 主线程被长任务占用，TBT或INP表现较差。

这类问题只更换CDN通常无法完全解决。CDN可以缩短静态资源传输和部分网络等待，但不能自动减少JavaScript执行时间，也不能修复页面布局跳动。

当前Core Web Vitals主要看LCP、INP和CLS。根据Web Vitals官方指标说明，评估时需要关注第75百分位表现，而不是只挑选一次跑得最好的结果。

为什么PageSpeed分数不错，CDNChart仍有地区很慢？

相反的情况也很常见。

PageSpeed实验室测试可能从北美、欧洲或亚洲的Google基础设施运行，具体测试位置和路线未必代表网站的主要用户。一个海外测试环境访问海外CDN节点很快，不等于中国大陆不同省份和运营商也能获得相同体验。

如果CDNChart显示以下情况，就应该优先调查CDN调度、节点覆盖、跨网路由、DNS解析或访问控制：

• 电信节点正常，部分移动节点连接时间明显偏高；

• 华东较快，西北、东北大量节点较慢；

• 不同地区解析到的响应IP差异很大；

• 某些地区出现403、5xx或访问失败；

• 请求发生多次重定向；

• 慢节点集中在某一个运营商。

这也是为什么在线测速必须选择真实用户所在地区。可以先阅读《在线网站测速，为什么要选用户所在的地区？》，再按照业务用户分布选择测试节点。面向国内用户的网站，应分别查看电信、联通、移动；面向海外用户的业务，则要覆盖主要国家和区域。

网站测速结果不一致，应该怎样逐项对照？

有效的对照方式不是把两个页面并排打开，看哪个数字大，而是按照“网络入口—服务器响应—资源传输—浏览器渲染—真实用户体验”的顺序排查。

第一步：固定完全相同的测试URL

先确认两个工具测试的是同一个地址，包括：

• HTTP还是HTTPS；

• www.example.com还是example.com；

• 首页还是具体内容页；

• URL路径和查询参数是否一致；

• 是否携带尾部斜杠；

• 是否跳转到登录页、地区页或移动版页面。

http://example.com、https://example.com和https://www.example.com/可能经历不同次数的重定向、使用不同证书或命中不同CDN配置。URL不一致时，后面的数字没有直接可比性。

建议优先测试真实用户最终访问的HTTPS地址，不要只测试中间跳转域名。

第二步：用CDNChart确定网络和CDN基线

把相同URL放入CDNChart网站测速工具，根据目标用户选择国内三网或海外节点。此时先不要急着看平均总耗时，而应依次检查下面这些结果。

1. HTTP状态码是否一致

   某些地区返回200，另一些地区出现403、502、503或超时，说明问题不只是“速度慢”，还可能涉及WAF规则、节点故障或回源异常。

2. 响应IP是否符合预期

   同一域名返回多个IP可能是正常的CDN调度。关键是慢节点是否集中解析到某几个响应IP，以及这些IP是否与异常地区存在明显关联。

3. 解析时间是否异常

   如果DNS解析本身就消耗较长时间，页面资源优化无法消除这段等待，应继续检查权威DNS、递归解析路径、CNAME链和调度配置。

4. 连接时间是否集中偏高

   连接慢而下载正常，通常更值得检查网络距离、跨网路由、节点可达性和TCP连接过程。

5. 下载和总耗时是否只在部分地区升高

   全国普遍慢和少数地区慢，处理方向不同。前者可能涉及源站、缓存策略或资源本身，后者更像节点、运营商和路由问题。

6. 是否发生额外重定向

   HTTP转HTTPS、裸域跳转www、地区跳转和登录跳转可以叠加。每一次跨域跳转还可能重新经历DNS、连接和TLS过程。

CDN测试方法与评分标准可以帮助确认测试节点与数据口径。这里得到的是主动探测结果，适合发现地区差异和当前异常，不应直接代替企业自己的真实用户监控。

第三步：把PageSpeed的现场数据与实验室数据分开记录

不要只抄下一个性能分数。至少应记录以下内容：

尤其不要用Lighthouse的TBT直接替代CrUX中的INP。二者都与页面响应能力有关，但测量方式和适用场景不同：TBT来自实验室页面加载过程，INP来自真实用户交互体验。

第四步：使用交叉判断表定位问题层级

这个对照表的意义，是把“哪个工具更准”改成“两个工具分别暴露了哪一层的问题”。

用curl补充确认每个请求阶段

当CDNChart显示某些节点异常，而PageSpeed又无法说明网络请求细节时，可以在有代表性的网络环境中运行：

curl -sS -o /dev/null \
  -w 'status=%{http_code}\nremote_ip=%{remote_ip}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\nredirects=%{num_redirects}\n' \
  https://www.example.com/

重点查看：

• status：最终HTTP状态码；

• remote_ip：实际连接到的IP；

• dns：完成域名解析时的累计时间；

• connect：建立TCP连接时的累计时间；

• tls：完成TLS握手时的累计时间；

• ttfb：收到首字节时的累计时间；

• total：整个请求的总时间；

• redirects：重定向次数。

curl的这些时间多数是从请求开始计算的累计时间，不能简单相加。例如，近似的TCP阶段耗时可以用connect - dns判断，TLS阶段则可以参考tls - connect。

如果需要区分CDN与源站，可以在已经确认源站IP且获得授权的前提下，保留域名、Host和TLS SNI进行源站测试：

curl -sS -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  -w 'status=%{http_code}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://www.example.com/

不要把URL直接替换成源站IP，也不要通过关闭证书验证来取得一个不可比的结果。--resolve能够让请求连接到指定IP，同时保留HTTPS域名和TLS SNI。

如果CDN请求明显慢于源站，需要检查CDN节点、回源连接或缓存配置；如果源站本身的TTFB已经很高，单纯更换CDN未必能解决动态页面和未缓存请求的问题。

一次测试不能作为优化验收结论

无论是CDNChart还是PageSpeed，单次测试都可能受到临时路由、节点负载、缓存冷热状态和第三方资源变化影响。

比较优化前后结果时，至少做到：

• 使用完全相同的URL；

• 保持相同的设备类型和测试入口；

• 在不同时间重复测试；

• CDNChart使用相同地区与运营商节点；

• 分别保存最快、最慢、平均值和失败节点；

• PageSpeed分开保存现场数据与实验室数据；

• 记录测试日期、发布时间和CDN配置变更时间；

• 不用一次最高分覆盖持续存在的慢节点。

关于不同工具产生差异的普遍原因，也可以结合《同一个网站，不同测速平台为什么差距很大？》继续检查节点位置、网络环境、缓存状态和指标定义。

拿到两份结果后，按这个顺序做决定

如果CDNChart发现大量失败节点或明显的运营商差异，先处理DNS、CDN调度、状态码、节点可达性和回源问题。用户连稳定打开页面都做不到时，优化LCP并不能解决基础可用性。

如果CDNChart各地区请求正常，而PageSpeed的LCP、TBT或CLS较差，重点转向首屏图片、渲染阻塞资源、JavaScript执行、字体和页面布局。

如果Lighthouse已经改善，但CrUX仍然较差，不要立即判定优化失败。先确认改动发布时间，再观察真实用户数据的滚动窗口，同时通过自己的RUM系统按国家、运营商、设备和页面类型细分。

如果两边都慢，则不要急着只换CDN或只压缩图片。把问题拆成DNS、连接、TTFB、下载、LCP、主线程阻塞和交互延迟，逐层找到占用时间最多的环节。

CDNChart与PageSpeed不是两个互相竞争的分数系统。前者帮助回答“用户能不能从正确节点稳定、快速地取得内容”，后者帮助回答“取得内容后，浏览器能不能迅速呈现并响应操作”。只有把这两层放在同一条访问链路上对照，网站测速结果不一致才会从一个令人困惑的现象，变成可以逐项定位的问题。