什么是 TBT？
Total Blocking Time (TBT) 指标衡量的是在首次内容绘制 (FCP) 之后，主线程被阻塞足够长的时间以至于阻止输入响应的总时长。
默认情况下，Lighthouse 会在可交互时间 (TTI) 之后停止监控 TBT，一些其他测量页面加载的实验室工具也是如此。请参阅TBT 与 TTI 有何关系？。
当存在长任务时，即在主线程上运行超过 50 毫秒的任务，主线程被视为“已阻塞”。我们说主线程是“已阻塞”的，因为浏览器无法中断正在进行的任务。因此，如果用户在长任务期间确实与页面进行交互，则浏览器必须等待任务完成才能做出响应。
如果任务足够长（超过 50 毫秒），用户很可能会注意到延迟，并认为页面运行缓慢或已损坏。
给定长任务的阻塞时间是其超过 50 毫秒的持续时间。页面的总阻塞时间是在测量的时段（对于页面加载工具通常为 TTI，对于其他工具则为总跟踪时间）内，FCP 之后发生的每个长任务的阻塞时间之和。
例如，请考虑以下浏览器主线程在页面加载期间的图表
上图所示的时间线包含五个任务，其中三个是长任务，因为它们的持续时间超过 50 毫秒。下图显示了每个长任务的阻塞时间
因此，虽然在主线程上运行任务的总时间为 560 毫秒，但只有 345 毫秒的时间被认为是阻塞时间。
| 任务持续时间（毫秒） | 任务阻塞时间（毫秒） | |
|---|---|---|
| 任务一 | 250 | 200 |
| 任务二 | 90 | 40 |
| 任务三 | 35 | 0 |
| 任务四 | 30 | 0 |
| 任务五 | 155 | 105 |
| 总阻塞时间 | 345 毫秒 | |
TBT 与 INP 有何关系？
TBT 早于 INP，可用作 INP 问题的指标，尤其是在实验室环境中，INP 更难测量。但是，TBT 可能会标记潜在问题，但在用户不在此时间交互的情况下，可能不会出现问题。并且，在实验室环境中测量时，它也可能会遗漏由交互引起的问题。我们建议在实际环境中使用 INP 来衡量用户体验到的实际响应速度问题。TBT 可能是实验室中 INP 的合理代理指标，但它不能替代 INP 本身。
TBT 与 TTI 有何关系？
TBT 是在一段时间内测量的。对于一些传统上测量页面加载的实验室工具（包括 Lighthouse）而言，TBT 一直测量到 TTI，因为它有助于量化页面在变得可靠交互之前可能处于非交互状态的严重程度。但是，TBT 也可以在页面加载之后甚至超过 TTI 的时间段内继续测量，例如在 Lighthouse Timespan 模式下。
TTI 认为，如果主线程在至少五秒钟内没有长任务，则页面“可靠地可交互”。这意味着，在 10 秒内分散的三个 51 毫秒的任务可能会像单个 10 秒长的任务一样，将 TTI 推迟很长时间，但对于尝试与页面交互的用户来说，这两种情况的感受会非常不同。
在第一种情况下，三个 51 毫秒的任务的 TBT 为 3 毫秒。而单个 10 秒长的任务的 TBT 为 9950 毫秒。第二种情况中较大的 TBT 值量化了更糟糕的体验。
此示例说明了为什么 TBT 通常比 TTI 更好，因为它不太容易出现异常值。即使使用 TTI 作为 TBT 的终点也是如此。
如何测量 TBT
TBT 是一项应该在实验室中测量的指标。测量 TBT 的最佳方法是在您的网站上运行 Lighthouse 性能审核。有关使用详情，请参阅关于 TBT 的 Lighthouse 文档。
在实际环境中使用 TBT 进行测量是可能的，但我们不建议这样做，因为用户交互可能会以导致报告中出现大量差异的方式影响您页面的 TBT。相反，如果您想了解单个 INP 交互之外的内容，我们建议您查看更新的实际环境中的 Long Animations Frame API。
实验室工具
良好的 TBT 分数是多少？
为了提供良好的用户体验，网站应力争在普通移动硬件上进行测试时，总阻塞时间少于 200 毫秒。
有关您页面的 TBT 如何影响您的 Lighthouse 性能得分的详细信息，请参阅Lighthouse 如何确定您的 TBT 分数
如何改进 TBT
总的来说，我们建议针对 INP 而不是 TBT 进行优化，因为我们建议在实验室中使用 TBT 作为 INP 的代理指标（在实验室中通常无法准确测量 INP）。因此，要改进 TBT，请查看我们关于优化 INP 的指南。
如果您专门关注 TBT，您可以运行 Lighthouse 性能审核，并注意审核建议的任何特定机会。
通常，改进网站的 TBT 涉及减少阻塞脚本的数量，这意味着优化它们以减少阻塞，或减少脚本的总量。请参阅以下性能指南