什么是 TBT？
总屏蔽时间 (TBT) 指标用于衡量从 First Contentful Paint (FCP) 之后主线程处于屏蔽状态的时间总���，此时主线程处于屏蔽状态的时间够长，足以阻止输入响应。
默认情况下，Lighthouse 会在 Time to Interactive (TTI) 后停止监控 TBT，其他一些用于衡量网页加载时间的实验室工具也是如此。请参阅 TBT 与 TTI 有何关系？。
每当存在长任务（即在主线程上运行超过 50 毫秒的任务）时，主线程都会被视为处于“阻塞”���态。我们之所以说主线程处于“阻塞”状态，是因为浏览器无法中断正在执行的任务。因此，如果用户在执行耗时任务期间确实与网页互动，浏览器必须等待任务完成才能响应。
如果任务用时足够长（超过 50 毫秒），用户可能会注意到延迟，并认为网页运行缓慢或已损坏。
给定长任务的阻塞时间是指其时长超过 50 毫秒。网页的总阻塞时间是指在测量时间范围内 FCP 之后发生的每项长任务的阻塞时间的总和（对于网页加载工具，通常是 TTI；对于其他工具，则是轨迹总时间）。
例如，请考虑下图，其中显示了网页加载期间浏览器的主线程：
上图中显示的时间轴包含五项任务，其中三项任务是长任务，因为它们的持续时间超过 50 毫秒。下图显示了每项长任务的阻塞时间：
因此，虽然在主线程上运行任务的总时间为 560 毫秒，但其中只有 345 毫秒被视为阻塞时间。
| 任务时长（毫秒） | 任务阻塞时间（毫秒） | |
|---|---|---|
| 任务 1 | 250 | 200 |
| 任务二 | 90 | 40 |
| 任务三 | 35 | 0 |
| 任务四 | 30 | 0 |
| 任务 5 | 155 | 105 |
| 总屏蔽时间 | 345 毫秒 | |
TBT 与 INP 有何关系？
TBT 早于 INP，可用作 INP 问题的指标，尤其是在测量 INP 更困难的实验室环境中。不过，如果用户当时没有互动，TBT 可能会标记可能存在的问题，即使用户可能没有遇到任何问题。此外，在实验室环境中进行测量时，它还可能会忽略由互动导致的问题。我们建议您在现场测量 INP，以衡量用户实际遇到的响应速度问题。对于实验室，TBT 可能是 INP 的合理代理指标，但它本身并不能替代 INP。
TBT 与 TTI 有何关系？
TBT 是在一段时间内衡量的。对于传统上用于衡量网页加载时间的某些实验室工具（包括 Lighthouse），TTB 的衡量范围一直延伸到 TTI，因为它有助于量化网页在变为能与用户进行可靠互动之前处于不可互动状态的时间（用严重程度表示）。不过，在页面加载后，系统也可以继续衡量 TBT，例如在 Lighthouse 的时间跨度模式下。
如果主线程至少 5 秒内没有长任务，TTI 会将网页视为“可靠地可互动”。这意味着，三个 51 毫秒的任务分布在 10 秒内，其 TTI 延迟时间与单个 10 秒的任务一样长，但对于尝试与网页互动的用户来说，这两种场景的感觉会截然不同。
在第一种情况下，三个 51 毫秒的任务的 TBT 为 3 毫秒。而单个时长为 10 秒的任务的 TBT 为 9950 毫秒。第二种情况下，TBT 值越大，体验就越差。
这个示例说明了为什么 TBT 通常比 TTI 更好，因为它不太容易出现离群值。即使 TTI 用作 TBT 的端点，也是如此。
如何衡量 TBT
TBT 是一个应在实验室中衡量的指标。衡量 TBT 的最佳方法是针对您的网站运行 Lighthouse 性能审核。如需了解使用详情，请参阅 Lighthouse 文档中的 TBT 部分。
您可以在现场衡量 TBT，但我们不建议这样做，因为用户互动可能会以各种方式影响网页的 TBT，导致报告中出现大量差异。不过，如果您想超越单次 INP 互动，我们建议您查看更高级的 Long Animations Frame API。
实验室工具
TBT 得分怎样才算理想？
为了提供良好的用户体验，网站应尽量确保在平均移动设备硬件上测试时，总屏蔽时间不超过 200 毫秒。
如需详细了解网页的 TBT 对 Lighthouse 性能得分的影响，请参阅 Lighthouse 如何确定 TBT 得分
如何改进 TBT
一般来说，我们建议优化 INP，而不是 TBT，因为我们建议在实验室中使用 TBT 作为 INP 的代理指标（在实验室中通常无法准确测量 INP）。因此，如需提高 TBT，请参阅我们的优化 INP 指南。
如果您要专门关注 TBT，可以运行 Lighthouse 性能审核，并注意审核中建议的任何具体优化机会。
一般来说，提高网站的 TBT 需要减少阻塞脚本的数量，这意味着要优化脚本以减少阻塞，或者减少总脚本数量。请参阅以下性能指南：