什麼是 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 的替代指標。
待定和 TTI 有何關聯？
觀察時間是一段時間。某些以傳統方式測量頁面負載 (包括 Lighthouse) 的實驗室工具是測量到 TTI 為止的測量結果，因為這類工具有助於量化非互動式網頁的嚴重程度，以此達到可靠的互動式體驗。不過，TTBT 仍可在網頁載入後繼續評估，涵蓋範圍則不僅限於 TTI，例如 Lighthouse 時間範圍模式。
如果主執行緒至少 5 秒內沒有長時間的工作，TTI 就會將網頁視為「可靠的互動性」。也就是說，如果有三個 51 毫秒的任務，分散在 10 秒的時間內，TTI 就會延遲到 10 秒，但對使用者來說，這兩種情況的感受會截然不同。
在第一種情況下，三個 51 毫秒的工作的 TBT 為 3 毫秒。而如果是單一 10 秒長的工作，則其 TBT 為 9950 毫秒。第二種情況中的 TBT 值較大，可量化較差的體驗。
這個例子說明了為何 TBT 通常比 TTI 更適合作為指標，因為 TBT 較不容易出現異常值。即使 TTI 用於 TBT 端點，也是如此。
如何評估 TBT
TBT 是研究室應測量的指標。測量 TBT 的最佳方式就是對網站執行 Lighthouse 效能稽核。如要進一步瞭解使用詳情，請參閱 TBT 的 Lighthouse 說明文件。
您可以自行測量實地測溫的數值，但我們不建議這麼做，因為使用者互動可能影響您網頁的估計值，因而導致報表變化不一。如果只想查看單次 INP 互動以外的內容，建議改用新版的「領域中的長動畫頁框 API」。
研究室工具
怎樣的 TBT 分數才算良好？
為了提供良好的使用者體驗，網站應力求在一般行動裝置硬體上測試時，總阻斷時間低於 200 毫秒。
如要進一步瞭解網頁的 TBT 對 Lighthouse 效能分數的影響，請參閱「Lighthouse 如何判定 TBT 分數」一文。
如何改善 TBT
一般來說，我們建議您針對 INP 而非 TBT 進行最佳化調整，因為我們建議使用 TBT 做為實驗室中 INP 的替代指標 (因為 INP 通常無法準確測量)。因此，如要改善 TBT，請參閱最佳化 INP的指南。
如果您需要特別關注 TBT，可以執行 Lighthouse 效能稽核，並特別留意稽核報告提出的任何特定商機。
一般來說，要改善網站的 TBT，就必須減少阻擋的腳本數量，也就是說，要麼是將腳本最佳化，減少阻擋的情況，要麼就是減少整體的腳本數量。請參閱下列成效指南：