Website Speed Test: 即刻开始并解释所有术语

Website Speed Test 的意思是：Largest Contentful Paint (LCP) 低于 2,5 秒，Interaction to Next Paint (INP) 低于 200 毫秒，Cumulative Layout Shift (CLS) 低于 0,1，均按真实访问的第 75 百分位计。 Google 就是这么写的，不是某个博客里说的。你要是只在柏林用自己的笔记本测，根本不知道拉各斯那边的页面什么样。

我多半先开 Chrome Inspector，在 Network 标签里看是不是某张图或某个视频特别吃带宽。然后 PageSpeed Insights。接着再换一个城市、换一个国家、换一个大洲测一次。

Lab 是机器。Feld 是人。

Lab （Lighthouse，在 PageSpeed Insights 的“诊断”里点一下）：固定设备，固定网络，没有真人在点。适合揪出一张肥大的 JPEG。不适合拿来给日本下结论。

Feld （Chrome User Experience Report，简称 CrUX）：真实 Chrome 用户，28 天，第 75 百分位。Google 就按这个数给页面打分。一个 Origin 要通过 Core Web Vitals，LCP、INP 和 CLS 在那里就都得是 “good”。

INP 已在 2024 年 3 月取代 First Input Delay (FID)。要是哪篇文章还把 FID 写成 Core Web Vital，那文章就过时了。

真正算数的阈值

指标	它测什么	好	一般	差
LCP	最大的可见那一块何时到位	≤ 2,5 s	2,5 s 到 4 s	> 4 s
INP	一次点击、轻触或按键到下一次绘制需要多长时间	≤ 200 ms	200 ms 到 500 ms	> 500 ms
CLS	布局在没有你干预的情况下移动了多少	≤ 0,1	0,1 到 0,25	> 0,25
TTFB	响应的第一个字节。不是 Core Web Vital，但是 LCP 的下限	≤ 0,8 s	0,8 s 到 1,8 s	> 1,8 s
FCP	第一个可见内容。诊断用，不是排名 Vital	≤ 1,8 s	1,8 s 到 3 s	> 3 s

三个 Vitals 的来源： web.dev/articles/vitals，最后更新于 2024 年 10 月 31 日，阈值 2026 年保持不变。TTFB： web.dev/articles/ttfb，截至 2025 年 11 月 18 日。FCP：同一 Vitals 家族，Lighthouse 把 1,8 s 用作“good”。

移动端和桌面端数字相同。这是按中等移动网络校准的。所以几乎每个 Origin 都先在手机上不达标。

20 分钟路径

1. Network 标签。 Chrome，F12，Network，Reload。按 Size 排序。超过 300 KB 且是图片的，就是首要嫌疑。
2. PageSpeed Insights. 字段 (CrUX) 和实验室 (Lighthouse) 在同一页。URL 填到上面的启动处。
3. 本地 Lighthouse。 DevTools, Tab Lighthouse, Kategorie Performance, Device Mobile. 和 PSI 里的 Lab 同一引擎，只是在你这边。
4. 第二座城市。 WebPageTest, Location Mumbai 或 São Paulo，不只是 “default”。如果那里的 TTFB 爆炸，服务器就在错误的区域或没有 CDN-Edge。
5. 第二个浏览器。 真机 iPhone 上的 Safari 说谎方式和 Pixel 上的 Chrome 不同。下面再说。

工具卡：哪个东西适合干什么

工具	测量	地点	价格感
PageSpeed Insights	CrUX 字段加 Lighthouse 实验室，LCP/INP/CLS	Lab：一个 Google 位置。字段：全球真实用户，聚合	免费
Chrome DevTools, Network + Performance + Lighthouse	Bytes, Waterfall, LCP-Element, Layout Shifts	你的书桌	免费
WebPageTest	Filmstrip, TTFB, LCP, Request-Waterfall, Script-Blocking	你选择城市、设备、连接	基础级免费，API 收费
GTmetrix	Lighthouse 加自己的瀑布图视图	少数固定区域，付费版更多	免费有限，其余订阅
CrUX / CrUX Vis	28 天字段，Origin 或 URL，如果流量足够	真实用户，无城市选择	免费
Search Console, Core Web Vitals 报告	你的 Property 的 URLs, 字段, 28 天	你的真实访客	免费, Property 必须已验证
DebugBear, SpeedCurve, Calibre	Monitoring, Budgets, Lab 在时间轴上	多个地区	订阅
Catchpoint	Synthetik plus RUM, Enterprise	一百多个站点	贵, 认真
UptimeRobot	机器是否响应, Response Time	少量探测站点	免费就够用了
Pingdom	Uptime plus 事务, Speed 在付费版	多个地区	订阅
BrowserStack, LambdaTest	页面是否在 Safari, Firefox, Edge, 旧 iPhone 上根本能运行	设备云, 没有速度排名	订阅

Uptime 不是 Speed. UptimeRobot 告诉你, 30 秒后是否还能收到 HTTP 200. 那里的 Response Time 大致是 TTFB, 不是 LCP. 我在那里有个账号, 因为“页面还活着”这个问题和“雅加达有人能不能看到 Hero”不是一回事.

为什么简单的速度测试把世界排除在外

PageSpeed Insights 在 Lab 里从一台 Google 电脑启动. 下面的 CrUX 对真实用户取平均, 不会向你展示东京对内罗毕. 对于有 DE 和 US 客户的商店页面, 这个平均值是公式正确的谎言.

谁想要全球可达性，就需要可选择地点的合成测试。WebPageTest 是免费入门：Location、Browser、4G。Catchpoint 和 DebugBear 是同样的东西作为长期订购。来自美国的可用性服务的一次 Ping 测量的是握手，不是最大的那张图。

DNS、TLS、首字节，然后 HTML，然后 CSS，然后 Hero 图。纽伦堡的 Origin 在法兰克福很快，在悉尼则先要在电缆上花 250 ms，然后才有人开始画像素。所以：这里测一次，那里测一次，然后才下判断。

不是 Chrome 的浏览器

Lighthouse 是 Chromium。iOS 上的 Safari 有不同的 JavaScript-JIT、不同的缓存规则、不同的字体加载。Firefox 把跟踪器推进严格模式。Chrome 里 Core Web Vitals 过关，说明不了 Safari 17 里的结账。

实际操作：

• 一部真正的 iPhone，Safari，把结账流程点一遍。不要只靠模拟器。
• Firefox，打开 Tracking Protection，Network 标签。Chrome 还放行的第三方脚本，在这里经常卡住。
• 如果你没有设备板：BrowserStack 或 LambdaTest：iPhone-Safari、一台旧 Samsung、iPad。这是功能测试。那里的速度很粗，因为农场不是你的 4G。
• WebPageTest 可以在选定城市的真实机器上跑 Chrome、Firefox、Edge。Safari-iOS 仍然靠实体设备或农场。

数字变红时，你在页面上拧什么

• LCP： Hero 用现代格式（AVIF 或 WebP），固定宽度， fetchpriority="high"，不要放在滑块后面。TTFB 低于 0,8 s，否则 LCP 达不到 2,5 s。
• INP： 主线程上的长任务。聊天小部件、标签管理器坟场、阻塞 400 ms 的 Hydration。实验室里的 Total Blocking Time 是代理指标，因为 Lighthouse 不点击。
• CLS： 给图片和嵌入设好宽度和高度。不要有 2 s 后从上面掉进来的横幅。字体用 font-display: swap 和宽度跑得差不多的合适回退字体。

文章里的 YouTube iframe 是典型的 CLS 和 LCP 元凶。Facades，也就是先出预览图、点击后再上播放器，在这里是常规，不是加分项。

用 AI 代理在 12 分钟内自己测量

你只需要 Node，别的都不要。代理写脚本，你拿它对着你的 URL 跑。

npx --yes lighthouse https://example.com --only-categories=performance --form-factor=mobile --chrome-flags="--headless" --output=json --output-path=./lh.json

然后无花哨的 TTFB：

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com

如果你想点击就用 Playwright（否则实验室里就没有 INP）：

npx --yes playwright install chromium
# ein 40-Zeilen-Skript: page.goto, page.click, performance.getEntries

给代理的提示，这就够了：“写一个 Node 脚本，用 Lighthouse 移动端跑这个 URL，从 JSON 抽出 LCP/TBT/CLS，并在旁边放上 curl-TTFB。除了 lighthouse 不要其他依赖。如果 LCP 超过 2,5 s 就 Exit 1。”

这替代不了 CrUX。它替代的是你手工把 40 个 URL 丢进 PSI 跑一下午。

谁想要多个城市又没有 Enterprise 合同：WebPageTest 有 API。一个代理可以连续触发三个 Location，把 JSON 摘要倒进一张表。这是通往“全球”的便宜路径，不用在孟买自己放一台机器。

自己的网站测速工具：什么值得做

把 Google 嵌进页面的 iframe 不干净。PageSpeed Insights 会发送 X-Frame-Options。就算可以，嵌入也会正好毁掉文章解释的那些指标。

三个级别，由低到高：

1. 入门版，如上。 一个字段，三个按钮，测试在 Google 和 WebPageTest 运行。建造时间：不到一小时。写在这篇文章里。
2. 来自自己机群的探测。 母舰上的一个小服务：URL 输入，从纽伦堡 (nbg1) 和法尔肯施泰因 (fsn1) 各一个 HEAD 加上 TTFB、DNS、TLS。两个德国站点，标为 DE。不是“全球”。建造时间：一个下午，如果 Agent 写服务而你已经有那些盒子。
3. 通过别人的眼睛看世界。 同样的界面，后面是 WebPageTest-API 或 Catchpoint-Lite。孟买、弗吉尼亚、圣保罗作为复选框。这就是简单测速所不是的那种产品。建造时间：v1 两天，外加 API 费用。

字段数据 (CrUX) 你可以在 Origin 有足够 Chrome 流量时通过 CrUX API 加上。低于阈值时瓷砖保持空，UI 必须这么说，而不是编造的数字。

我们不该建的：读者浏览器标签里的 Lighthouse 克隆，假装自己是世界。它朝和点一下 PSI 同一个方向撒谎。

事实表

陈述	篮子	来源
Core Web Vitals 2026：LCP ≤ 2,5 s，INP ≤ 200 ms，CLS ≤ 0,1，各 75. 百分位，移动和桌面相同阈值	事实	web.dev/articles/vitals，截至 31.10.2024。2026 行业文本确认良好阈值未变。
INP 在 2024 年 3 月取代 FID 成为 Core Web Vital	事实	同一页面，LCP、CLS、INP 的 Lifecycle Stable。
TTFB 良好 ≤ 0,8 s，差 > 1,8 s，75. 百分位。不是 Core Web Vital	事实	web.dev/articles/ttfb，截至 18.11.2025。
FCP 良好 ≤ 1,8 s，在 HTTP Archive / web.dev 的 CrUX 定义中	事实	httparchive.org/reports/chrome-ux-report，“Good First Contentful Paint”。
PSI-Lab 来自一个地点，CrUX 平均真实用户无城市过滤	事实	PageSpeed Insights 产品，CrUX 文档。
这篇文章里的 PSI iframe 会让页面自身的 LCP 和 CLS 变差	论点	MDN 关于 iframe 成本，加上 Google 工具的 X-Frame-Policy。
两个 Hetzner 站点 (nbg1, fsn1) 对来自德国的 TTFB 够用，对“global”不够	论点	线路的物理特性加上我们的机群。Mumbai 仍是另一种测量。

来源

1. https://web.dev/articles/vitals: Core Web Vitals，阈值，实验室对比实地。
2. https://web.dev/articles/ttfb: TTFB 定义和 0,8 / 1,8 s。
3. https://web.dev/articles/lcp · https://web.dev/articles/inp · https://web.dev/articles/cls
4. https://pagespeed.web.dev/: PageSpeed Insights。
5. https://developer.chrome.com/docs/crux: Chrome User Experience Report。
6. https://www.webpagetest.org/: 选择站点。
7. https://httparchive.org/reports/chrome-ux-report: 跨 Origins 的实地分布。
8. https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Performance/HTML: iframe 成本。
9. https://github.com/GoogleChrome/lighthouse: 用于代理运行的 CLI。

阈值截取：2026 年 9 月 16 日，对照 web.dev。自 2024 年 INP 切换以来，良好数值没有变动。