总阻塞时间 (TBT) 是测量加载响应度的重要实验室指标，因为该项指标有助于量化在页面交互性变为可靠前，不可交互程度的严重性，较低的 TBT 有助于确保页面的可用性。
总阻塞时间 (TBT) 指标测量First Contentful Paint 首次内容绘制 (FCP)与Time to Interactive 可交互时间 (TTI)之间的总时间，这期间，主线程被阻塞的时间过长，无法作出输入响应。
每当出现长任务（在主线程上运行超过 50 毫秒的任务）时，主线程都被视作"阻塞状态"。我们说主线程处于"阻塞状态"是因为浏览器无法中断正在进行的任务。因此，如果用户在某个长任务运行期间与页面进行交互，那么浏览器必须等到任务完成后才能作出响应。
如果任务时长足够长（例如超过 50 毫秒），那么用户很可能会注意到延迟，并认为页面缓慢或卡顿。
某个给定长任务的阻塞时间是该任务持续时间超过 50 毫秒的部分。一个页面的总阻塞时间是在 FCP 和 TTI 之间发生的每个长任务的阻塞时间总和。
例如，请看以下这张页面加载期间浏览器主线程的图表：
上方的时间轴上有五个任务，其中三个是长任务，因为这些任务的持续时间超过 50 毫秒。下图显示了各个长任务的阻塞时间：
因此，虽然在主线程上运行任务的总时间为 560 毫秒，但其中只有 345 毫秒被视为阻塞时间。
| 任务持续时间 | 任务阻塞时间 | |
|---|---|---|
| 任务一 | 250 毫秒 | 200 毫秒 |
| 任务二 | 90 毫秒 | 40 毫秒 |
| 任务三 | 35 毫秒 | 0 毫秒 |
| 任务四 | 30 毫秒 | 0 毫秒 |
| 任务五 | 155 毫秒 | 105 毫秒 |
| 总阻塞时间 | 345 毫秒 | |
TBT 是 TTI 的一个出色的配套指标，因为 TBT 有助于量化在页面交互性变为可靠前，不可交互程度的严重性。
TTI 会在主线程至少有五秒钟没有长任务时，认为页面具备"可靠交互性"。也就是说，分布在 10 秒钟里的三个 51 毫秒长的任务与单个 10 秒长的任务对 TTI 的影响是相同的，但对于试图与页面进行交互的用户来说，这两种情况给人的感觉是截然不同的。
在第一种情况下，三个 51 毫秒的任务的 TBT 为3 毫秒。而单个 10 秒长的任务的 TBT 为9950 毫秒。第二种情况下较大的 TBT 值对较差的体验进行了量化。
TBT 指标应该在实验室中进行测量。测量 TBT的最佳方法是在您的网站上运行一次灯塔性能审计。有关使用详情，请参阅灯塔中关于 TBT 的说明文档。
虽然 TBT 可以在实际情况下进行测量，但我们不建议这样做，因为用户交互会影响您网页的 TBT，从而导致您的报告中出现大量差异。如需了解页面在实际情况中的交互性，您应该测量First Input Delay 首次输入延迟 (FID) 。
为了提供良好的用户体验，网站在普通移动硬件上进行测试时，应该努力将总阻塞时间控制在300 毫秒以内。
有关页面 TBT 对灯塔性能分数影响的详细信息，请参阅灯塔如何确定您的 TBT 分数
如需了解如何改进某个特定网站的 TBT，您可以运行一次灯塔性能审计，并留心查看审计建议的各种具体机会。
如需了解改进 TBT 的常见方式（针对任何网站），请参阅以下性能指南：
Total Blocking Time (TBT)This post introduces the Total Blocking Time (TBT) metric and explains how to measure it 
