PerformanceLongAnimationFrameTiming：blockingDuration 属性
blockingDuration是PerformanceLongAnimationFrameTiming接口的只读属性，它返回一个DOMHighResTimeStamp，以毫秒为单位表示主线程被阻止响应高优先级任务（如用户输入）的总时间。
描述
blockingDuration的计算方法是，将 LoAF 中所有duration超过50ms的长任务，从每个任务中减去50ms，然后将渲染时间添加到最长任务时间，并将结果相加。让我们通过一个例子来阐明这究竟意味着什么。
假设一个 JavaScript 文件需要总共 145ms 的时间来处理。在脚本的前一部分在 65ms 内处理完后，我们可以考虑将剩余脚本的执行拆分成第二个任务，这个第二个任务需要 80ms 的时间来执行。将处理拆分成这样两个任务，而不是作为一个任务来执行整个脚本，这是可取的，因为它可以让浏览器有机会在任务之间处理用户交互。这种方法被称为让步。例如，您可以在脚本的前一部分执行完之后插入一个setTimeout()来让步。
这里有三种关于脚本如何最终被处理的选项需要考虑
- 如果我们在前 65ms 后让步，浏览器可以决定在运行脚本的其余部分之前渲染一帧。
- 或者，浏览器也可以先运行脚本的其余部分，然后再渲染帧。
- 我们也可以决定不让步，让浏览器将整个脚本作为一个任务来处理。
注意：浏览器通常会尝试优先处理重要的任务，比如用户交互和渲染新帧，而不是它可能已排队的不太重要的任务。浏览器尝试每 16ms 渲染一个新帧。
我们之前提到脚本的总处理时间为 145ms。假设渲染 UI 更新的时间为 10ms，那么这三种选项中 LoAF 的时间如下所示
| 选项 | duration（LoAF 1） |
blockingDuration（LoAF 1） |
duration（LoAF 2） |
blockingDuration（LoAF 2） |
|---|---|---|---|---|
| 1 | 65ms | 15ms (65 - 50) | 80ms | 40ms (80 + 10 - 50) |
| 2 | 145ms (65 + 80) | 55ms ((65 - 50) + (80 + 10 - 50)) | n/a* | n/a* |
| 3 | 145ms (65 + 80) | 105ms ((65 + 80) + 10 - 50) | n/a* | n/a* |
* 在选项 2 和 3 中，只有一个 LoAF。
请注意，前两种选项中的总blockingDuration是相同的（55ms）——在这两种情况下，浏览器都决定以不同的方式来拆分工作。
然而，选项 3 的blockingDuration要长得多，因为浏览器完全被阻塞，无法中断长任务。这突出了通过让步来优化长任务的重要性——无论浏览器如何决定处理任务，只要让步，阻塞时间总是会比完全不让步要短。
LoAF 的duration和blockingDuration之间的区别可以概括如下
duration是 LoAF 总响应时间的度量，它有助于理解帧的布局、绘制等是否花费了很长时间。blockingDuration是 LoAF 阻止主线程响应高优先级任务（如用户交互）的总时间的度量，这会导致 UI 感觉卡顿。换句话说，它是 LoAF 对响应能力的影响的度量。
每个任务的blockingDuration计算为duration - 50ms的原因是，用户可以感知到超过 50ms 的响应延迟。当用户开始注意到迟钝时，这个阈值就出现了；因此，超过 50ms 的时间对于确定卡顿的严重程度至关重要。有关更多详细信息，请参见总阻塞时间 (TBT)。
值
示例
有关长动画帧 API 相关的示例，请参见长动画帧计时。
规范
| 规范 |
|---|
| 长动画帧 API # dom-performancelonganimationframetiming-blockingduration |
浏览器兼容性
BCD 表格仅在启用 JavaScript 的浏览器中加载。
另请参阅
- 长动画帧计时
PerformanceScriptTiming- 优化长任务 on web.dev (2024)