什麼是 TBT？
「總封鎖時間」(TBT) 指標會測量「首次顯示內容所需時間」(FCP) 後的總時長，此時主執行緒會封鎖足夠的時間，以防止輸入內容做出回應。
根據預設，Lighthouse 會在互動準備時間 (TTI) 後停止監控 TBT，其他用於評估網頁載入時間的實驗室工具也是如此。請參閱「TBT 與 TTI 有何關聯？」一文。
只要有長時間工作 (在主執行緒上執行超過 50 毫秒的工作)，主執行緒就會被視為「封鎖」。我們會說主執行緒「遭到阻斷」，是因為瀏覽器無法中斷正在進行的工作。因此，如果使用者在長時間工作階段中確實與網頁互動，瀏覽器必須等待工作完成才能回應。
如果工作時間過長 (超過 50 毫秒)，使用者可能會注意到延遲情形，並認為網頁速度緩慢或有問題。
指定長時間工作任務的阻斷時間，是指其超過 50 毫秒的時間長度。網頁的總封鎖時間，是指在測量時間範圍內，在 FCP 之後發生的每個長時間工作任務的封鎖時間總和 (通常是網頁載入工具的 TTI，或其他工具的總追蹤時間)。
舉例來說，請參考下圖，瞭解瀏覽器在網頁載入期間的主要執行緒：
上圖所示的時間軸包含五項工作，其中三項為長時間工作，因為其持續時間超過 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)，測試人員會將 TBT 測量結果與 TTI 進行比較，因為這有助於量化網頁在可靠地互動前，非互動程度的嚴重程度。不過，TBT 也可以在網頁載入後繼續評估，因此可用於評估 TTI 後的時間，例如在 Lighthouse 時間範圍模式中。
如果主執行緒至少 5 秒內沒有長時間的工作，TTI 就會將網頁視為「可靠的互動性」。也就是說，如果有三個 51 毫秒的子工作，分散在 10 秒的時間內，TTI 就會延遲到 10 秒，但對使用者來說，這兩種情況的感受會截然不同。
在第一種情況下，三個 51 毫秒的工作的 TBT 為 3 毫秒。而單一 10 秒長的工作，其 TBT 為 9950 毫秒。第二種情況中的較大 TBT 值可量化較差的體驗。
這個例子說明瞭為何 TBT 通常比 TTI 更適合作為指標，因為 TBT 較不易出現異常值。即使 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，就必須減少阻擋的腳本數量，也就是說，要麼是將腳本最佳化，減少阻擋的情況，要麼就是減少整體的腳本數量。請參閱下列成效指南：