什么是 TBT？
总阻塞时间 (TBT) 指标用于衡量在 First Contentful Paint (FCP) 之后主线程被阻塞的时间足以阻止输入响应的总时间。
默认情况下，Lighthouse 会在 Time to Interactive (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），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，但我们不建议您这样做，因为用户互动可能会影响网页的 TBT，从而导致报告出现大量差异。如果您不想局限于单一 INP 互动，我们建议您查看较新的在实际应用中使用的 Long Animations Frame API。
实验室工具
好的 TBT 分数是多少？
为了提供良好的用户体验，在一般移动设备硬件上进行测试时，网站应力求将总阻塞时间控制在 200 毫秒以内。
如需详细了解您网页的 TBT 如何影响您的 Lighthouse 性能得分，请参阅 Lighthouse 如何确定您的 TBT 得分
如何提高 TBT
一般来说，我们建议优化 INP，而不是 TBT，因为我们建议在实验室（通常无法准确衡量 INP）中使用 TBT 作为 INP 的代理指标。因此，如需提高 TBT，请参阅我们的优化 INP 指南。
如果您要专门关注 TBT，可以运行 Lighthouse 性能审核，并注意审核中建议的任何具体优化机会。
一般来说，提高网站的 TBT 需要减少阻塞脚本的数量，这意味着要优化脚本以减少阻塞，或者减少总体脚本数量。请参阅以下性能指南：