Lighthouse检测Total Blocking Time偏高，与Long Task分析结果不符

TBT的实际计算逻辑 #

TBT的计算并非简单累加所有长任务超出50ms的部分，它有明确的时间范围限制：仅统计First Contentful Paint (FCP) 到 Time to Interactive (TTI) 这个时间段内的长任务。

具体规则：

• 长任务定义：主线程执行时长超过50ms的任务。
• 对每个符合条件的长任务，取「任务时长 - 50ms」作为该任务的阻塞贡献值。
• 将所有贡献值累加，得到最终的TBT数值。

为什么你的TBT远高于预期？ #

你预期TBT为40ms，但Lighthouse结果平均1300ms，可能是以下原因：

1. 漏看了FCP-TTI窗口内的长任务 #

你只发现了1个90ms的长任务，但Lighthouse统计的是FCP到TTI之间的所有长任务。可能存在大量你没注意到的长任务（比如多个60ms的小长任务，每个贡献10ms，累计起来数值会很高），或者你关注的那个长任务根本不在FCP-TTI的时间范围内，不算入TBT。

2. 节流环境导致任务时长被放大 #

Lighthouse默认会启用4倍CPU节流（模拟中低端设备性能），同时模拟3G网络。在这种环境下，原本本地测试中耗时不足50ms的任务，可能会因为CPU被限制而超过50ms，变成长任务；原本90ms的任务，可能会被拉长到几百毫秒，贡献的阻塞时间也会大幅增加。你本地分析时可能没有开启节流，所以看到的任务时长远短于Lighthouse检测的结果。

3. 长任务的检测工具或视角差异 #

你自己分析长任务时，可能用的工具没有完整捕捉到主线程的所有任务，或者没有聚焦在FCP到TTI的时间窗口内。Lighthouse的检测逻辑会更严格，会把所有在该窗口内的主线程阻塞任务都算入，包括一些异步执行的代码片段、第三方脚本等。

验证建议 #

• 打开Lighthouse报告的「长任务」详情面板，查看FCP到TTI时间段内的所有长任务列表，逐个计算（时长-50ms）的总和，确认是否和TBT数值匹配。
• 在Chrome DevTools的Performance面板中，开启和Lighthouse相同的CPU/网络节流设置，重新录制主线程任务，对比你之前的分析结果。
• 检查第三方脚本、框架初始化代码等是否在FCP之后执行，这些通常是长任务的主要来源。

内容的提问来源于stack exchange，提问作者Kyrielight