同一个页面地址，分别丢进两款网站测速工具，两边给出的分数经常差出二十多分。头一回碰上的人会怀疑其中一个坏了，多测几次才发现两个都正常，它们量的东西本来就不一样。

为写这篇，我把几家常被点名的测速工具的官方说明和定价页翻了一遍。翻的过程中撞见一件小事。GTmetrix 的免费额度，我找到的三份资料给了三个说法，一份写每月 5 次、共 3 个月，一份写每天 50 次，还有一份写免费只能用温哥华一个节点。工具改政策比文章快得多，下面凡涉及额度和价格的地方，我只给大致范围，具体数字去它的定价页当场确认。

网站测速工具的分数为什么对不上

测速工具的数据来源分两种，混着看必然对不上。

实验室数据由工具在固定环境里跑一遍。同一台机器、同一段网络，清空缓存，从零开始加载。它可以重复，适合在改版前后做对照。PageSpeed Insights 的 Performance 分数、Chrome 里的 Lighthouse、GTmetrix 的 Performance 分数，都属于这一类。

真实用户数据来自真实访客。Google 的 CrUX 收的是 Chrome 用户过去大约 28 天的访问记录，按 75 分位取值。Core Web Vitals 的官方判定用的就是这一套。

两边打架的时候，先信真实用户数据，再拿实验室数据去找原因。

这里有个门槛很少有人提。CrUX 只收录流量足够的站点，新站或者日访问量很小的页面，PageSpeed Insights 会直接写源站数据不足，只剩实验室那一栏。它表示这个页面还没攒够可以统计的用户数据，跟真实用户快不快没有关系。

五个工具分别在量什么

这五款是现在提到网站性能测试时最常被点名的选择。下面按用途过一遍，它们的数据口径并不相同。

Google PageSpeed Insights

pagespeed.web.dev

一个页面一次给两块数据，上面是 CrUX，下面是 Lighthouse。它是唯一一个把 Google 判定时实际参考的数据直接摊在你面前的免费工具。移动端和桌面端分开看，默认走移动端。短板也明显，它只给分数和诊断清单，不给请求之间的排队关系。LCP 显示 4 秒却不知道是哪张图拖的，这种情况很常见。

GTmetrix

gtmetrix.com

它的 Performance 分数建立在 Lighthouse 之上，和 PageSpeed 的实验室分数同源，权重与阈值是否一致由各自决定，两个数字不必相等。它有价值的部分是瀑布图，能看出哪个 CSS、哪张图片、哪段第三方脚本在拖时间。免费账号可选的测试节点少，换地区、换设备要付费。额度和价格变动频繁，用之前自己确认一次。

WebPageTest

webpagetest.org

做性能排查的技术人员更愿意用它。它在真实浏览器和真实网络上跑，不做模拟，可选地点有几十个，支持多步测试（先打开页面，再点某个按钮，量第二步的耗时），也能看每隔 100 毫秒的截图序列。做改版前后的对比时，逐帧画面比任何分数都有说服力，拿去跟客户或者老板讲也省事。代价是界面门槛高，忙的时候测试要排队。

WebPageTest 由 Patrick Meenan 创建，现在由 Catchpoint 维护，项目开源。个人用的免费额度基本够，也提供 API 接进流水线。

Pingdom Website Speed Test

tools.pingdom.com

给不想看瀑布图的人用。填一个地址，选节点，出来一个 A 到 F 的等级，加上加载时间、页面体积和请求数。它不往下钻，你也不会被一堆指标淹掉。跟不做技术的人沟通，或者每周例行看一眼，这个足够。

Chrome 自带的 Lighthouse

按 F12，找到 Lighthouse 面板，点一下就开跑。它和 PageSpeed 用的是同一套测试逻辑，不过跑在你自己的机器上，CPU 和网络比模拟环境宽松，分数通常比 PageSpeed 那一栏好看。这一点要记住，本地 95 分不代表线上用户觉得快。它的另一个好处是能测 localhost，改动还没上线就能先量一遍。

想把它放进流程，可以用官方的 Lighthouse CI，把性能分数卡在合并请求上，掉下来就不让过。性能回归大多发生得悄无声息，多挂一个分析脚本，多放一张没压过的图，一次掉几个点，攒三个月才被发现。

另外两个不花钱的口径

Google Search Console 的 Core Web Vitals 报告按 URL 分组，告诉你哪些页面在真实用户那里不达标。数据来源和 CrUX 一致，但按组呈现，改起来更有头绪。

打算自建的话，官方的 web-vitals 库能直接把 LCP、INP、CLS 报回你自己的接口，配 sendBeacon 在页面关闭前发出去。这是唯一能让你看到自己用户的分布而不是一个平均值的办法。

按处境组合，别只用一个

你要做的事 先用的 再用的
判断 SEO 表现 Search Console 的 CWV 报告 PageSpeed Insights 里的 CrUX
找出到底哪里慢 GTmetrix 的瀑布图 WebPageTest 深挖网络与第三方脚本
上线前验证 本地 Lighthouse PageSpeed Insights 复核线上
防止改版变慢 Lighthouse CI 卡阈值 定期跑同一页面留历史
多地区的访客体验 WebPageTest 换节点 自建 web-vitals 上报看分布

一个人管一两个站，第一列的两三样就够，不必马上开付费账号。站点数量上来，或者开始给客户交付，多地区、定时监控、历史曲线和告警才有意义。

分数不是目标

Lighthouse 的 Performance 分数由五项加权得出。Total Blocking Time 占 30%，LCP 和 CLS 各占 25%，FCP 和 Speed Index 各占 10%。TBT 权重最高，原因和 INP 有关。INP 在 2024 年 3 月替代了原来的 FID，成为三项 Core Web Vitals 之一。实验室里没有人点击页面，量不出 INP，只能拿 TBT 当替身。TBT 干净，不等于真实用户按下去就有反应。

还有一件事早点知道比较好。Google 用真实用户数据做判定，页面体验在排序里属于次要因素，权重要低于内容相关性和链接。把分数从 78 刷到 95 而砍掉页面功能，通常不划算。会疼的地方在别处，移动端转化率、广告收入和跳出率，都跟着页面加载速度走，一次糟糕的首屏足以让访客直接走掉。

常见问题

测速分数每次都不一样，正常吗

正常。实验室测试受本机负载、网络波动、第三方脚本响应速度影响。看趋势，别看单次。同一页面连续跑三次取中位，或者用带历史记录的工具。

CrUX 显示数据不足怎么办

说明这个页面或者这个源站的 Chrome 访问量还没到收录门槛。这时候可以看 Search Console 的分组报告，也可以自建 web-vitals 上报，等自己的数据攒够。

免费工具够不够用

个人管一两个站，PageSpeed Insights 加本地 Lighthouse 加 Search Console，基本够。需要多地区、定时监控、历史曲线和告警，再考虑付费。

实验室分数和 CrUX 差很多，以哪个为准

以 CrUX 为准，它是 Google 判定时使用的数据。实验室分数用来验证改动的方向，比如把首屏那张大图换成 WebP 之后重新跑一遍，看 LCP 有没有降下来。

结论

2026 年没有一款网站测速工具能单独给出完整答案。判断 Google 那边看到的成绩，看 PageSpeed Insights 里的 CrUX 和 Search Console 的分组报告。找慢在哪一步，用 GTmetrix 的瀑布图加 WebPageTest 的多地点深测。守住上线质量，把 Lighthouse 放进本地流程和 CI。分数是量出来的中间结果，访客愿不愿意留下才决定最后的生意。

关键来源