总阻塞时间（TBT）：公式、示例和降低方法

什么是总阻塞时间？

总阻塞时间（Total Blocking Time，TBT）衡量页面加载期间主线程被阻塞、无法响应用户输入的时间。它把首次内容绘制到可交互时间（Time to Interactive）之间每个长任务（超过 50 毫秒的任务）的「阻塞」部分加起来。

TBT = Σ (每个长任务的时长 − 50 毫秒)

留出 50 毫秒，是因为 50 毫秒以内的任务仍能让浏览器在大约 100 毫秒内响应点击，感觉上是即时的；超出的部分，就是用户不得不等待的时间。

TBT 是实验室指标：Lighthouse 等工具在受控加载中测量它。它对应的现场响应性指标是 Interaction to Next Paint。

计算示例

首次内容绘制之后，主线程上跑了五个任务（示例跟踪）：

只要把水合拆成五段各 50 毫秒，就能单独去掉 200 毫秒 TBT，工作量一点没少，因为每段之间浏览器都能处理输入。

TBT 阈值

Lighthouse 对移动端 TBT 的评级大致为：

Lighthouse 10 及以后，TBT 占性能得分的 30%，权重高于其他任何指标。

TBT、FID 和 INP

实验室里 TBT 很高，强烈预示真实用户的 INP 会差，在慢手机上尤其如此。但 TBT 只覆盖加载阶段，INP 还能抓到之后的慢互动。

怎么降低 TBT

1. 拆分长任务。 把工作切成小段，中间把主线程让出来（比如用 scheduler.yield() 或 setTimeout）。
2. 少发 JavaScript： 删掉没用的代码，按路由拆分，避免大体积的 polyfill。
3. 延后或懒加载第三方脚本，比如聊天组件、A/B 测试和标签管理器，等用户互动或空闲后再加载。
4. 少做水合： 局部或渐进式水合、服务端组件、孤岛架构。
5. 把繁重工作挪到 Web Worker。
6. 避免布局抖动：不要在循环里交替读写布局属性。

在 TapCub 里

TBT 需要受控的实验室运行，TapCub 测量的是真实访问，所以不报告它。性能报表给出 TBT 所预测的现场指标：衡量响应性的 INP，以及 LCP、CLS、首字节时间和首次内容绘制，可以按页面、设备和浏览器看 P75 或 P95。开发时用 Lighthouse 找出长任务，再在 TapCub 里看 INP，确认真实用户感受到了改善。TapCub 脚本本身体积小，加载时不阻塞解析。见核心网页指标和合成监控。

参考资料

• web.dev. Total Blocking Time (TBT).
• Chrome for Developers. Lighthouse: Total Blocking Time.
• web.dev. Optimize long tasks.