CDN测速和网站测速有什么区别？分别能测出什么

网站打开慢，很多人的第一反应是：找个测速工具跑一下。

可真正打开工具以后，问题又来了。有的页面显示CDN延迟、可用性和吞吐量，有的显示DNS解析、连接和下载耗时，还有的给出LCP、CLS、INP以及一长串前端优化建议。

它们都叫“测速”，测的却不是同一件事。

先说结论：CDN测速主要观察内容分发网络在不同地区和线路下的传输表现；网站测速主要检查某个真实域名或页面的访问情况。如果要知道用户看到的完整网页什么时候显示出来、能不能顺畅操作，还需要浏览器级的页面加载测试。

所以，严格来说，我们平时口中的测速至少可以分成三类：

把这三类测试分开以后，很多看似矛盾的结果就能解释了：CDN排名很快，网站仍然可能很慢；某个URL响应很快，完整页面也可能迟迟显示不出来。

CDN测速，测的是内容分发网络本身的表现

如果你的问题是“哪个CDN速度快”“Cloudflare和CloudFront怎么比较”“国内用户应该优先测试哪几家CDN”，需要看的首先是CDN性能测试。

这类测试通常会尽量控制测试条件。例如，让不同CDN提供相同或接近的测试文件，从不同地区持续发起请求，再按照统一规则汇总结果。

这样做的目的，是减少文件大小、测试时间和统计方式不同造成的干扰。

在CDNChart的全球CDN排行榜和CDN厂商对比中，常见指标包括：

• P50延迟：一半样本的延迟低于这个数值，用来观察较典型的访问表现；

• P95延迟：95%的样本不超过这个数值，更容易发现慢请求和尾部体验；

• 可用性：测试周期内请求成功的比例；

• 吞吐量：单位时间能够传输多少数据，对图片、视频和大文件下载更有参考价值；

• 地区与运营商表现：同一家CDN在不同地区、不同网络下是否存在明显差异；

• 样本数和更新时间：这份结论建立在多少次观测上，以及数据是否仍然具有时效性。

CDN测速适合做横向比较，却不能直接回答“我的首页为什么打开慢”。

原因很简单：统一测试文件不是你的真实网站。你的缓存规则、源站速度、页面代码、图片大小和第三方脚本，都不会因为某家CDN在标准测试中表现靠前而自动变好。

CDN性能排名更适合用来建立候选名单，而不是直接代替上线测试。

CDNChart如何统一测试对象、使用P50/P95以及处理样本，可以参考主动探测测速方法和测评方法论。

网站测速，先要看测的是“一个请求”还是“完整页面”

“网站测速”这个词最容易产生误会。

有些网站测速工具测试的是一个域名或URL的HTTP访问过程；另一些工具会启动真实或模拟浏览器，加载HTML、CSS、JavaScript、图片、字体和第三方资源。

两者都在测试网站，但得到的结论不同。

先看第一种：多地区HTTP测速。

在CDNChart网站测速中输入真实域名，可以从中国电信、中国联通、中国移动以及海外监测位置发起请求，查看解析、连接、下载耗时和响应IP等信息。

它适合解决这些问题：

• 同一个网站在不同地区访问速度是否接近；

• 电信访问正常，移动或联通是否明显偏慢；

• 网站接入CDN以后，不同地区返回的响应IP是否发生变化；

• 某个地区是DNS解析慢、连接慢，还是资源下载慢；

• 网站是否存在局部失败、超时或异常状态码。

这类结果测试的是一个具体请求。它会受到目标URL、测试地区、运营商、缓存状态和测试时间影响，所以测试时最好使用同一个URL，记录时间并重复几次。

如果第一次测试的是首页，第二次换成一张已经缓存的图片，两次结果就没有直接可比性。一次在晚高峰测试、一次在凌晨测试，也不能简单算出“接入CDN后快了多少”。

完整网页测速，关注的是用户看到和操作页面的过程

一个HTTP请求结束，并不代表网页已经能用了。

浏览器拿到HTML以后，还可能继续请求几十甚至几百个资源。JavaScript需要下载和执行，图片需要解码，字体可能阻塞文字显示，广告、统计和客服组件也可能拖慢页面。

这时候，需要使用浏览器的Network和Performance工具，或者Google PageSpeed Insights进行完整页面测试。

Google对PageSpeed Insights的说明指出，它会分别报告移动设备和桌面设备的页面体验，并提供改进建议。其结果可能包括实验室环境测试，以及具有足够数据时的真实用户体验信息。具体可以查看PageSpeed Insights官方文档。

完整页面测试通常会关注：

• LCP：页面主要内容大约什么时候显示出来；

• CLS：加载过程中页面是否发生意外跳动；

• INP：真实用户与页面交互时，页面响应是否及时；

• 请求瀑布图：各项资源什么时候开始、等待多久、下载多久；

• 资源数量和页面体积：页面是否加载了过多脚本、图片或字体；

• 阻塞与执行时间：是不是网络已经返回，浏览器却仍在忙着执行JavaScript。

LCP、INP和CLS是当前的Core Web Vitals，分别反映加载、交互和视觉稳定性。指标定义可以查看web.dev的Web Vitals说明。

浏览器加载测试非常适合排查“测速显示响应很快，用户却觉得页面很慢”的情况。

Chrome开发者工具中的Network瀑布图，可以查看不同请求的先后关系、响应头、大小与耗时，操作方法见Chrome Network官方文档。

一个具体例子：为什么CDN很快，网站还是慢

假设某家CDN在统一测试中的P50延迟表现很好，你的网站多地区HTTP测试也没有明显连接异常，但首页仍要几秒钟才显示完整。

这时候继续更换CDN，未必能解决问题。

真正的原因可能是：

• 首页HTML没有缓存，每次都需要等待源站生成；

• 首屏图片很大，没有压缩或使用合适格式；

• JavaScript文件过多，并且在页面渲染前执行；

• 页面引用了响应很慢的第三方统计、广告或客服服务；

• 字体文件加载较晚，导致文字迟迟不能稳定显示；

• CDN缓存没有命中，请求仍然频繁回源。

CDN测速能够说明网络分发层的部分表现，多地区HTTP测速能够帮助定位请求在哪些地区或阶段偏慢，而浏览器完整页面测试才能继续找出具体是哪一个资源、脚本或渲染环节拖慢了页面。

三种测试不是互相替代，而是逐层缩小问题范围。

怎么选择测试工具？先看你想回答什么问题

如果只是想快速判断，可以记住一句话：

选CDN，看统一条件下的CDN测速；查地区访问问题，测自己的真实域名；查页面为什么慢，再看完整网页加载过程。

不依赖网页工具，也可以快速查看一次HTTP请求

在macOS或Linux中，可以使用curl查看一个URL的基础耗时：

curl -sS -o /dev/null \
  -w 'DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' \
  'https://www.example.com/'

操作时把示例地址换成自己的真实URL。

这里显示的是从请求开始计算的累计时间点，并不是几个可以直接相加的独立阶段。

例如，time_starttransfer表示从开始到收到第一个字节的时间，其中已经包含前面的域名解析、连接以及服务器处理过程。字段定义可以查看curl官方手册。

这条命令适合快速对照同一个URL在不同时间的变化，但它只代表运行命令这台设备所在的网络，也不会执行网页中的JavaScript。

一套更可靠的组合测试方法

如果你正在排查网站速度，可以按下面的顺序做：

1. 确定测试对象。 分别准备首页URL和一张应该被CDN缓存的公开静态资源，不要把两者结果混在一起；
   

2. 做多地区HTTP测速。 在CDNChart中测试真实域名，记录地区、运营商、响应IP、各阶段耗时和失败情况；
   

3. 检查浏览器请求。 用Chrome Network重新加载页面，找出等待时间长、体积大或加载失败的资源；
   

4. 查看页面体验。 使用PageSpeed Insights或自己的真实用户监测，观察LCP、CLS、INP及优化建议；
   

5. 一次只改一个主要条件。 调整缓存、压缩或页面资源后，使用相同URL、相近时间和相同测试位置复测；
   

6. 保留失败和慢请求。 不要只截图最快的一次，连续记录更容易看出问题是否稳定存在。
   

如果刚刚接入CDN，还需要先确认域名解析、请求路径与缓存行为是否符合预期。

上一篇《CDN加速有没有生效？接入后这样检查》正式发布后，可以在这里增加对应的文章内链。

几个容易混淆的问题

Ping很快，能说明网站打开快吗？

不能。

Ping主要反映ICMP往返情况，不会替你完成HTTPS协商、等待服务器响应、下载页面资源或执行JavaScript。部分网络还会限制ICMP，因此Ping只能作为一种连通和延迟线索。

网站测速结果很好，为什么用户仍然说慢？

先核对用户所在地区、运营商、设备、访问时间和具体页面。

你的测试可能命中了缓存，用户可能遇到冷缓存；你测试的是首页HTTP响应，用户感受到的可能是某个第三方脚本造成的页面卡顿。

CDN测速排名靠前，能直接证明它适合我的网站吗？

不能。

排名可以帮助建立候选名单，但最终还要用自己的文件、域名、缓存规则和主要用户地区做测试，同时考虑价格、备案、技术支持和安全需求。

只做一次测速够不够？

通常不够。

网络会随地区、运营商和时间波动。排查问题时至少保持测试对象一致并重复测试；做正式选型时，还应该覆盖主要地区和业务高峰时段。

测速的价值，不是得到一个越小越好的数字

测速最怕的，不是数据少，而是拿错数据回答问题。

你想比较CDN厂商，却拿自己的复杂首页作为唯一依据；你想排查页面渲染，却只盯着一个HTTP总耗时；你想证明接入后变快，却没有保存接入前的测试条件——最后即使得到很多数字，也很难做出判断。

更有效的做法，是先问清楚：我现在要比较CDN、检查真实域名，还是排查完整页面？

如果你想先看看网站在不同地区和运营商下的实际访问情况，可以打开CDNChart网站测速，输入自己的域名完成一次多地区测试。

记录这次的URL、时间和测试范围，再去做下一次对照，结果才真正有用。