發布日期：2019 年 11 月 7 日，上次更新日期：2025 年 10 月 15 日
什麼是 TBT？
「總封鎖時間」(TBT) 指標可測量首次顯示內容所需時間 (FCP) 之後的總時長，於此期間系統會封鎖主執行緒足夠的時間，防止其對輸入內容做出回應。
根據預設，Lighthouse 會在互動時間後停止監控 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 更是實用。不過，如果使用者當時沒有互動，即使沒有問題，TBT 仍可能會標示潛在問題。此外，在實驗室環境中進行測量時，也可能錯過因互動而導致的問題。建議您在實際環境中評估 INP，藉此瞭解使用者遇到的實際回應問題。在實驗室中，TBT 可能是 INP 的合理替代指標，但本身並非 INP。
TBT 與 TTI 有何關聯？
TBT 是在一段時間內測得的指標，對於傳統上用來評估網頁載入的某些實驗室工具 (包括 Lighthouse)，系統會評估 TTI 之前的 TBT，因為這有助於量化網頁在可穩定互動前無法互動的嚴重程度。不過，網頁載入後，系統仍可繼續評估 TBT，因此 TBT 可能會超過 TTI，例如在 Lighthouse Timespan 模式下。
如果主執行緒至少有五秒未執行冗長工作，TTI 就會將網頁視為「可穩定互動」。也就是說，如果 3 項 51 毫秒的工作分散在 10 秒內執行，可能會將 TTI 延後，與單一 10 秒長的工作一樣。不過，使用者嘗試與網頁互動時，這兩種情況的感受會大不相同。
在第一種情況下，三個 51 毫秒的工作的 TBT 為 3 毫秒。而單一 10 秒長的工作則會產生 9950 毫秒的 TBT。第二種情況的 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，就必須減少封鎖指令碼的數量，也就是最佳化指令碼，減少封鎖時間，或是減少指令碼總數。請參閱下列成效指南：