24 个首页的 total blocking time：只有 2 个落在 200 毫秒线以内

实测 · 2026-09-30 · 24 个首页 · Lighthouse 单次

样本与口径：24 个首页（含我们自有的 4 个站），2026-09-30 由 Lighthouse 13.5.0 以 mobile 配置各加载一次，我们读每份报告里的 total-blocking-time 审计。每站只跑一次，不取平均、不复测。

total blocking time 是没有真实用户时用来代替响应速度的 lab 数字，在这批样本上它普遍很难看。24 个首页里只有 2 个落在 web.dev 定的 200 毫秒线以内。中位数首页把主线程阻塞了约 6.7 秒，24 个里有 21 个超过 500 毫秒，最差的一个 22.4 秒。

怎么测的

total blocking time 的定义是：首次内容绘制之后，每一个长任务超出 50 毫秒的部分相加，而长任务指主线程上任何跑超过 50 毫秒的任务（web.dev，2026-09-30 访问）。Lighthouse 是在一台固定的移动设备档位加限速网络下算出来的，所以这些数字之间可比，但每一个都不是某个真人访客的真实体验。

我们对每个域名跑一次 headless Lighthouse，只开加载相关的审计，并且保留原始值而不是四舍五入后的值。这 24 个域名是我们做其他横截面测量时用的那批面板，去掉拒绝自动化浏览器的站，再加上我们自有的 4 个。每份报告是一次加载，而一次加载就是这个站的全部样本。

total blocking time 的结果：只有两个首页过了线

这颗指标公开的合格线，是在平均移动硬件上低于 200 毫秒。有两个站过了。一个是静态的百科页面，另一个是框架官网，我们跑的那次它几乎没加载什么会阻塞的东西。其余全部没过，好几个差了一个数量级。

比榜首更值得看的是这条曲线有多长。同一台模拟设备上，最好和最差之间差了 22 秒以上的阻塞时间，这说明这颗指标量的不是网络、也不是硬件，而是每个团队在没人要求之前选择跑了多少 JavaScript。

total blocking time 不是你页面有多慢，而是访客还什么都没做之前，你的页面决定占用了主线程多少。

这些数字证明不了什么

它量的是阻塞，不是体验，两件事不是一回事。一个页面可以把主线程阻塞好几秒，而对一个在这段时间里从没交互过的人来说毫无感觉；反过来，一个阻塞时间很低的页面，如果用户点的那一下正好落在坏时机，照样会很卡。web.dev 真正为「响应速度」定义的指标是 interaction to next paint，total blocking time 是它在 lab 里的代理，不是替代（Chrome for Developers，2026-09-30 访问）。想要那颗指标本身，看 interaction to next paint 那一章。

另一个限制是样本。上面每一个数都是一次加载，而 Lighthouse 的读数本身有噪音：同一个站换台机器、换一天，值可能差出好几千毫秒。我们没给任何站跑第二遍，所以给不出单次读数有多稳。穿过噪音留下来的，是那条形状——少数几个站停在几百毫秒，一大截尾巴在几千毫秒——而这个形状和这些站是怎么搭出来的是对得上的。

这对你意味着什么

一条命令就能拿到你自己的数，不需要账号。

npx lighthouse https://example.com/ \
  --only-audits=total-blocking-time \
  --output=json --output-path=tbt.json --quiet

• 有 field 数就先读 field 数。阻塞时间用来解释一次差的交互结果，不能替代它。
• 把 200 毫秒这条线当成「用户真正点的那一下」的目标，不是当成加载的目标。
• 别跨设备拿你的分去比上面那张表。我们的数字全是同一台机器、同一天。
• 别靠多上 JavaScript 去修一次慢交互。多数时候，修法是少上一点。

常见问题

你们是怎么测的

2026-09-30 每个首页跑一次 headless Lighthouse，mobile 配置，从 JSON 输出里读 total-blocking-time 审计。不复测、不平均、不掺 field 数据。原始报告按域名逐份留着，样本是 24 个同类型页面：首页。

total blocking time 是排名因素吗

不是，它代替的那颗 Core Web Vitals 也不是，除了页面体验整体上算一项输入之外没有别的。值得管它的理由是：一个阻塞好几秒的页面，没法快速回应一次点击，而点击是大多数访客会做的事。

为什么和我从 PageSpeed Insights 看到的数不一样

因为 PageSpeed Insights 能显示真实用户的 field 数据，本地 Lighthouse 不能。两者对不上时，field 数描述的是你的访客，而这个 lab 数只能帮你解释它。想了解旁边那颗加载指标，看 largest contentful paint。

该优化 total blocking time 还是 interaction to next paint

能量到交互那颗就优化交互那颗。阻塞时间是手边只有 lab 时的选择，它通常也能指出哪些脚本值得砍。如果你还在纠结这一周值不值得花，我们诚实的答案在 core web vitals 值不值得做。

下一步

这个数好拿，也没什么可争的。拿到你自己的，找出加载时就跑的脚本，砍掉那些没人会想念的。盯着访客真正落地那些页面的阻塞时间，正是 QueryWin 在做的事之一。