PerformanceLongAnimationFrameTiming: blockingDuration 屬性
PerformanceLongAnimationFrameTiming 介面的只讀屬性 blockingDuration 返回一個 DOMHighResTimeStamp，指示主執行緒因響應高優先順序任務（例如使用者輸入）而被阻塞的總時長（以毫秒為單位）。
描述
blockingDuration 的計算方法是：取 LoAF（長幀動畫時序）中 duration 大於 50ms 的所有 長任務，從每個任務中減去 50ms，將渲染時間加到最長任務時間上，然後將結果相加。讓我們透過一個例子來闡明這一點。
假設一個 JavaScript 檔案總共需要 145 毫秒來處理。在指令碼的第一個主要部分處理完 65 毫秒後，我們可以考慮將剩餘指令碼的執行拆分成第二個任務，第二個任務需要 80 毫秒來執行。與將整個指令碼作為一個任務執行相比，這樣拆分執行更有利，因為它讓瀏覽器有機會在任務之間處理使用者互動。這種方法被稱為讓步（yielding）。例如，您可以在指令碼的第一個主要部分執行完畢後插入一個 setTimeout() 來讓步。
這裡有三種指令碼可能的處理方式可供考慮：
- 如果在前 65 毫秒後讓步，瀏覽器可以在執行剩餘指令碼之前決定渲染一幀。
- 或者，瀏覽器可以先執行剩餘的指令碼，然後再渲染幀。
- 我們也可以選擇不讓步，讓瀏覽器將整個指令碼作為一個任務來處理。
注意： 瀏覽器通常會嘗試優先處理重要任務，例如使用者互動和渲染新幀，而不是它可能排隊的次要任務。瀏覽器會嘗試每 16 毫秒渲染一幀。
我們之前提到指令碼的總處理時間為 145 毫秒。假設 UI 更新的渲染時間為 10 毫秒，則三種情況下 LoAF 的時序如下：
| 選項 | duration (LoAF 1) |
blockingDuration (LoAF1) |
duration (LoAF2) |
blockingDuration (LoAF2) |
|---|---|---|---|---|
| 1 | 65毫秒 | 15毫秒 (65 - 50) | 80毫秒 | 40毫秒 (80 + 10 - 50) |
| 2 | 145毫秒 (65 + 80) | 55毫秒 ((65 - 50) + (80 + 10 - 50)) | 不適用* | 不適用* |
| 3 | 145毫秒 (65 + 80) | 105毫秒 ((65 + 80) + 10 - 50) | 不適用* | 不適用* |
* 在選項 2 和 3 中，只有一個 LoAF。
請注意，前兩種情況下的總 blockingDuration 相同（55 毫秒）—— 無論哪種情況，瀏覽器都決定以不同的方式拆分工作。
然而，選項 3 的 blockingDuration 要長得多，因為瀏覽器完全被阻塞，根本無法中斷長任務。這凸顯了最佳化長任務透過讓步的重要性——無論瀏覽器如何決定處理任務，阻塞持續時間仍將比不讓步時要短。
duration 和 blockingDuration 之間差異的 LoAF 可以總結如下：
duration是 LoAF 總響應時間的度量，它有助於理解幀的佈局、繪製等是否花費了很長時間。blockingDuration是 LoAF 阻塞主執行緒響應高優先順序任務（如使用者互動）的總時長的度量，這可能導致 UI 感覺 卡頓。換句話說，它是 LoAF 對響應能力影響的度量。
每個任務的 blockingDuration 計算為 duration - 50ms 的原因是，響應延遲超過 50 毫秒後用戶就能感知到。這個閾值是使用者開始注意到遲鈍的時候；因此，為了確定卡頓的嚴重程度，測量超過 50 毫秒的部分非常重要。有關更多詳細資訊，請參閱 總阻塞時間 (TBT)。
值
示例
有關 Long Animation Frames API 的示例，請參閱 長動畫幀計時。
規範
| 規範 |
|---|
| Long Animation Frames API # dom-performancelonganimationframetiming-blockingduration |
瀏覽器相容性
載入中…
另見
- 長動畫幀計時
PerformanceScriptTiming- 最佳化長任務 - web.dev (2024)