什么是 TBT？
总阻塞时间 (TBT) 指标衡量在首次内容绘制 (FCP) 之后，主线程处于阻塞足够长的时间以防止输入响应所用的总时长。
默认情况下，在可交互时间 (TTI) 之后，Lighthouse 会停止监控 TBT，一些其他测量页面加载的实验室工具也是如此。请参阅 TBT 与 TTI 有何关联？。
每当存在长任务（一种在主线程上运行时间超过 50 毫秒 (ms) 的任务）时，主线程就会被视为“阻塞”。我们称主线程处于“阻塞”状态，因为浏览器无法中断正在进行的任务。因此，如果用户在长时间的任务过程中与页面进行了互动，浏览器必须等待任务完成才能响应。
如果任务的时间足够长（超过 50 毫秒），用户很可能会注意到延迟并认为网页运行缓慢或卡顿。
给定耗时较长的任务的阻塞时间是指超过 50 毫秒的时长。网页的总阻塞时间是指每个长任务在 FCP 后在测量时间范围内（通常是 TTI，对于其他工具，为总跟踪时间）的总阻塞时间。
例如，下图显示了网页加载期间的浏览器主线程：
上面的时间轴有五个任务，其中三个任务是长时间运行的任务，因为其时长超过 50 毫秒。下图显示了每个耗时较长的任务的阻塞时间：
因此，虽然在主线程上运行任务所花费的总时间为 560 毫秒，但只有 345 毫秒的时间会被视为阻塞时间。
| 任务时长 | 任务阻塞时间 | |
|---|---|---|
| 任务 1 | 250 毫秒 | 200 毫秒 |
| 任务 2 | 90 毫秒 | 40 毫秒 |
| 任务 3 | 35 毫秒 | 0 毫秒 |
| 任务 4 | 30 毫秒 | 0 毫秒 |
| 任务 5 | 155 毫秒 | 105 毫秒 |
| Total Blocking Time | 345 毫秒 | |
TBT 与 TTI 有什么关系？
TBT 衡量的是一段时间内的指标。对于传统上测量网页加载速度的一些实验室工具（包括 Lighthouse），TBT 直到 TTI 才开始测量，因为它有助于量化网页在变为可靠的互动之前的非交互式程度。不过，TBT 也可以在页面加载后继续进行测量，在 TTI 之后也会继续测量，例如在 Lighthouse 时间跨度模式下。
如果主线程至少有 5 秒没有长任务，TTI 就会将页面视为“可交互”。这意味着，如果 3 个时长为 51 毫秒的任务分在 10 秒内，那么 TTI 就相当于一项时长为 10 秒的任务，而这两种情形对于尝试与网页互动的用户来说感觉截然不同。
在第一种情况下，3 个 51 毫秒的任务的 TBT 为 3 毫秒。而一项时长为 10 秒的任务的 TBT 为 9950 毫秒。对于第二个任务，TBT 值越大。
此示例说明了为什么 TBT 通常比 TTI 更好的指标，因为它不易出现离群值。TTI 用作 TBT 端点时，也是如此。
如何衡量 TBT
TBT 是一个应在实验室中衡量的指标。衡量 TBT 的最佳方法是在您的网站上运行 Lighthouse 性能审核。如需了解使用详情，请参阅关于 TBT 的 Lighthouse 文档。
实验工具
良好的 TBT 得分是多少？
为了提供良好的用户体验，在普通移动硬件上测试网站时，应力争使总阻塞时间低于 200 毫秒。
如需详细了解页面的 TBT 对 Lighthouse 性能得分的影响，请参阅 Lighthouse 如何确定您的 TBT 得分
如何改进 TBT
如需了解如何针对特定网站改进 TBT，您可以运行 Lighthouse 性能审核，并注意审核建议的任何特定机会。
如需了解如何从总体上改进 TBT（针对任何网站），请参阅以下性能指南：