公開日: 2019 年 11 月 7 日、最終更新日: 2025 年 10 月 15 日
TBT とは
Total Blocking Time（TBT）指標は、First Contentful Paint（FCP）の後にメインスレッドが入力の応答性を妨げるほど長くブロックされていた合計時間を測定します。
デフォルトでは、Lighthouse は Time to Interactive（TTI）の後に TBT のモニタリングを停止します。これは、ページ読み込みを測定する他のラボツールも同様です。TBT と TTI の関係をご覧ください。
メインスレッドが「ブロック」されていると見なされるのは、50 ミリ秒以上メインスレッドで実行されるタスクである長時間実行タスクがある場合です。進行中のタスクをブラウザが中断できないため、メインスレッドが「ブロック」されていると言います。そのため、ユーザーが長いタスクの途中でページを操作した場合、ブラウザはタスクが完了するまで待機してから応答する必要があります。
タスクが十分に長い場合（50 ミリ秒を超える場合）、ユーザーは遅延に気づき、ページが遅い、または壊れていると感じる可能性があります。
特定の長いタスクのブロック時間は、50 ミリ秒を超えた時間です。ページの合計ブロック時間は、測定期間（通常はページ読み込みツールの TTI、または他のツールの合計トレース時間）の FCP の後に発生する各ロングタスクのブロック時間の合計です。
たとえば、ページの読み込み中のブラウザのメインスレッドの次の図について考えてみましょう。
上の図のタイムラインには 5 つのタスクがあり、そのうち 3 つは 50 ミリ秒を超えるため、長いタスクです。次の図は、各長時間タスクのブロック時間を示しています。
したがって、メインスレッドでタスクを実行した合計時間は 560 ミリ秒ですが、そのうち 345 ミリ秒のみがブロック時間と見なされます。
| タスクの所要時間（ミリ秒） | タスクのブロック時間（ミリ秒） | |
|---|---|---|
| タスク 1 | 250 | 200 |
| タスク 2 | 90 | 40 |
| タスク 3 | 35 | 0 |
| タスク 4 | 30 | 0 |
| タスク 5 | 155 | 105 |
| Total Blocking Time | 345 ミリ秒 | |
TBT と INP はどのように関連していますか？
TBT は INP よりも前から存在しており、INP の問題を示す指標として役立ちます。特に、INP の測定が難しいラボ環境で役立ちます。ただし、ユーザーがその時点で操作を行わない場合、TBT はユーザーに問題がない可能性のある問題を報告することがあります。また、ラボ環境で測定した場合、相互作用によって発生する問題を見逃す可能性もあります。ユーザーが実際に体験した応答性の問題を測定する指標として、フィールドで INP を測定することをおすすめします。TBT はラボの INP の妥当なプロキシ指標になる可能性がありますが、INP 自体の代わりにはなりません。
TBT と TTI の関係
TBT は一定期間にわたって測定されます。Lighthouse など、従来からページ読み込みを測定する一部のラボツールでは、ページが安定してインタラクティブな状態になるまでの非インタラクティブな状態の重大度を定量化できるため、TBT は TTI まで測定されてきました。ただし、TBT はページ読み込み後、たとえば Lighthouse の Timespan モードで TTI を超えて測定されることもあります。
TTI では、メインスレッドが 5 秒以上長いタスクから解放されている場合、ページは「確実にインタラクティブ」であると見なされます。つまり、51 ミリ秒のタスクが 10 秒間に 3 つ分散している場合、1 つの 10 秒間の長いタスクと同じくらい TTI が遅延する可能性があります。ただし、ページを操作しようとしているユーザーにとっては、この 2 つのシナリオはまったく異なるものに感じられます。
最初のケースでは、3 つの 51 ミリ秒のタスクの TBT は 3 ミリ秒になります。一方、1 つの 10 秒間のタスクの TBT は 9, 950 ミリ秒になります。2 番目のケースでは、TBT の値が大きくなることで、ユーザー エクスペリエンスの悪化が数値化されます。
この例は、外れ値の影響を受けにくい TBT が TTI よりも優れた指標であることが多い理由を示しています。これは、TTI が TBT のエンドポイントとして使用されている場合でも同様です。
TBT の測定方法
TBT は、ラボで測定する必要がある指標です。TBT を測定する最善の方法は、サイトで Lighthouse のパフォーマンス監査を実行することです。使用方法について詳しくは、Lighthouse の TBT に関するドキュメントをご覧ください。
フィールドで TBT を測定することは可能ですが、ユーザーの操作によってページの TBT が変動し、レポートのばらつきが大きくなる可能性があるため、おすすめしません。単一の INP インタラクションを超えて確認したい場合は、代わりに新しい Long Animations Frame API in the field をご覧になることをおすすめします。
ラボツール
TBT スコアの目安はどのくらいですか？
優れたユーザー エクスペリエンスを提供するには、平均的なモバイル ハードウェアでテストしたときに、サイトの合計ブロック時間が 200 ミリ秒未満になるようにします。
ページの TBT が Lighthouse のパフォーマンス スコアに与える影響について詳しくは、Lighthouse が TBT スコアを決定する方法をご覧ください。
TBT を改善する方法
一般に、TBT よりも INP を最適化することをおすすめします。TBT はラボで INP のプロキシ指標として使用することをおすすめします（通常、INP を正確に測定することはできません）。したがって、TBT を改善するには、INP の最適化に関するガイダンスをご覧ください。
TBT に特に注目する場合は、Lighthouse のパフォーマンス監査を実行し、監査で提案された特定の改善案に注意を払います。
一般的に、サイトの TBT を改善するには、ブロッキング スクリプトの量を減らす必要があります。つまり、ブロッキング スクリプトを最適化してブロッキングを減らすか、スクリプトの総量を減らす必要があります。次のパフォーマンス ガイドを参照してください。