什么是 TBT？
总阻塞时间 (TBT) 指标用于衡量在 First Contentful Paint (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 与 TTI 有何关系？
TBT 是在一段时间内衡量的。对于一些传统上测量页面加载情况的实验室工具（包括 Lighthouse），TTI 一直测量到 TTI，因为它有助于量化页面在变为可靠可交互之前处于非交互状态的严重程度。不过，在页面加载后也可以继续测量 TBT，因此除了 TTI 之外，例如在 Lighthouse 时间跨度模式下。
如果主线程至少在 5 秒内没有长时间任务，TTI 会将页面视为“可靠交互”页面。这意味着 3 个时长为 51 毫秒的任务分布在 10 秒内，与单个时长为 10 秒的任务差不多可以将 TTI 延迟 - 但对于尝试与页面交互的用户来说，这两种情况会感觉截然不同。
在第一个示例中，三个时长为 51 毫秒的任务的 TBT 为 3 毫秒。而单个 10 秒长任务的 TBT 为 9, 950 毫秒。第二种情况下的 TBT 值越大，表示体验越差。
此示例说明为什么 TBT 通常比 TTI 更好，因为它不易出现离群值。即使将 TTI 用作 TBT 的端点也是如此。
如何衡量 TBT
TBT 是一个应该在实验中衡量的指标。衡量 TBT 的最佳方法是在您的网站上运行 Lighthouse 性能审核。如需了解使用详情，请参阅关于 TBT 的 Lighthouse 文档。
实验工具
什么是好的 TBT 分数？
为了提供良好的用户体验，在一般移动设备硬件上进行测试时，网站应力求将总阻塞时间控制在 200 毫秒以内。
如需详细了解您网页的 TBT 如何影响您的 Lighthouse 性能得分，请参阅 Lighthouse 如何确定您的 TBT 得分
如何改善 TBT
如需了解如何提高特定网站的 TBT，您可以运行 Lighthouse 性能评估，并关注该审核建议的任何特定机会。
若要从整体上了解如何改善 TBT（针对任何网站），请参阅以下效果指南：