総ブロッキング時間（TBT）

TL;DR — Total Blocking Time（TBT）は、ページの読み込み中にページがフリーズしている時間（クリックやタップに応答できない時間）を測定します。Lighthouseのようなラボツールは、最初の描画からページが操作可能になるまでの間にメインスレッドがブロックされた時間をすべて合計します。200 ms未満が良好です。これはラボ専用の数値であり、Core Web Vitalsではありません。Search Consoleには表示されません。

TBTとは

ページが読み込まれるとき、ブラウザには1つのメインスレッドがあり、JavaScriptの実行、ページの構築、クリックへの反応といった重い処理を行います。メインスレッドは一度に1つのことしかできません。JavaScriptの塊がそのスレッドを長時間占有すると、ページは一時的に応答不能になります。ボタンをタップしても、スクリプトが終了するまで何も起こりません。

Total Blocking Timeは、読み込み中のまさにそのフリーズ時間を測定したものです。Lighthouseのようなテストツールは、管理された環境でページを読み込み、メインスレッドを監視し、入力に応答できない状態でブロックされていた時間をすべて合計します。

50msルール

すべての作業がカウントされるわけではありません。ブラウザは短いタスクを、ユーザーが気づかないうちに処理できます。基準は50ミリ秒です。それより長く実行されるタスクは「長いタスク」と呼ばれ、50 msを超える部分だけがブロック時間としてカウントされます。

つまり、70 ms実行されるタスクはTBTに20 ms加算されます。40 ms実行されるタスクは何も加算されません。TBTは、ページの読み込み中に発生する「50 ms超」の部分の合計です。

良いスコアとは？

Lighthouseのモバイルでの基準：

• 良好： 200 ms以下
• 改善が必要： 600 msまで
• 不良： 600 ms超

多くの人が誤解していること

TBTはCore Web Vitalsではありません。 3つのCore Web VitalsはLCP、INP、CLSです。TBTは、Googleが実際に使用する実際のユーザーメトリクスであるInteraction to Next Paint（INP）を予測するのに役立つラボツールです。TBTはページの読み込みをシミュレートして測定されるため、実際の訪問者を監視するものではなく、Google Search Consoleやフィールドデータには表示されません。

完全な仕組み（具体的な例、LighthouseでTBTが最も重みを持つ理由、TBTとINPの違い、実際の修正方法）を知りたいですか？Advancedタブに切り替えてください。

TL;DR — TBTは、First Contentful PaintからTime to Interactiveまでの間に、メインスレッドが入力応答を妨げるほど長くブロックされた時間の合計です。すべての長いタスク（50 msを超えるメインスレッドタスク）のブロック部分（実行時間 − 50 ms）を合計します。これはラボメトリクスであり、Lighthouse 10スコアで最大の重み（30%）を持ち、INPのラボ上の代替指標ですが、Core Web Vitalsではなく、CrUXやSearch Consoleには表示されません。モバイルのしきい値：良好 ≤200 ms、不良 >600 ms。INPを修正するのと同じように修正します。長いJSタスクを分割し、コード分割し、未使用のJSを遅延/削除し、サードパーティスクリプトを抑制します。私の正直な見解：ランキング向上のためではなく、ユーザーのために修正してください。

TBTが実際に測定するもの

Googleの定義から始めるのが良いでしょう。TBTとは*「First Contentful Paint（FCP）の後、メインスレッドが入力応答を妨げるほど長くブロックされた時間の合計」*です。ブラウザのメインスレッドは一度に1つのタスクを処理します。長い処理に忙しい間は、クリック、タップ、キー入力に反応できません。TBTは、ページの読み込みウィンドウのうち、そのブロックされた状態に費やされる時間を定量化します。

ここで重要な定義は2つあります：

• 長いタスクとは、*「メインスレッドで50ミリ秒以上実行されるタスク」*です。
• タスクのブロック部分は、その実行時間から50 msを引いたものです。50 ms以下のタスクは、正確に0 msを加算します。

TBTは、FCPから**Time to Interactive（TTI）**までの間にあるブロッキング部分の合計です。つまり、First Contentful Paintがスタートラインです。最初のペイントより前は何もカウントされません。なぜなら、まだ画面上に操作できるものがないからです。

具体的な例

Google自身の表が最も明確な例です。FCPとTTIの間にメインスレッドで5つのタスクが実行されると想像してください。

タスク3と4は50 msのライン未満なので、何も寄与しません。タスク1は250 − 50 = 200 ms、タスク5は155 − 50 = 105 msブロックします。ブロッキング部分を合計すると — 200 + 40 + 0 + 0 + 105 — 345 msのTBTになります。これは「改善が必要」スコアであり、ほぼ2つの重いタスクによって引き起こされています。

ここが直感に反する部分で、ぜひ理解しておきたい点です：“A small number of tasks on the main thread doesn’t necessarily mean low blocking time. Conversely, a large number of tasks doesn’t necessarily lead to tons of blocking time.” (翻訳) 「メインスレッド上のタスクの数が少ないからといって、必ずしもブロッキング時間が短いとは限りません。逆に、タスクの数が多いからといって、必ずしも大量のブロッキング時間につながるとは限りません。」（この表現はNitroPackのもので、ここで紹介しています — ライブソースに対して2026-07-18に再検証済み。）重要なのは、個々のタスクが50 msを超えるかどうかであり、タスクの数ではありません。

測定ウィンドウ: FCPからTTIまで

ウィンドウはTime to Interactiveで終わります — “the time from when the page starts loading to when its main sub-resources have loaded and it is capable of reliably responding to user input quickly.” (翻訳) 「ページの読み込みが始まってから、主要なサブリソースが読み込まれ、ユーザーの入力に迅速かつ確実に応答できるようになるまでの時間。」Lighthouseでは、TTIは、長いタスクがなく、進行中のネットワークリクエストが2つ以下の5秒間の「静かなウィンドウ」を前方に検索することで見つけられます。

注目すべき点：TTI自体はLighthouse 10から削除されました。なぜなら、外れ値のネットワークリクエストや長いタスクに過度に敏感で、変動が大きくなることが判明したからです。TBTは存続し、主要なインタラクティブ性の指標となりました。Philip Waltonが述べたように、“Newer, alternative, metrics like Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Interaction to Next Paint (INP) are usually better metrics to use in place of TTI.” (翻訳) 「Largest Contentful Paint (LCP)、Total Blocking Time (TBT)、Interaction to Next Paint (INP)などの新しい代替指標は、通常、TTIの代わりに使用するのに適した指標です。」TBTはウィンドウの終了点としてTTIを置き換えたわけではありません — 同じ根本的な問題に対するより優れた単一の数値です。また、LighthouseレポートUIからTTIが消えたことは、TTIがLighthouseのデフォルトのナビゲーションウィンドウを制限しなくなったという主張と同じではありません — ウィンドウ自体は今でも内部的にそのように測定されています。

もう1つの範囲に関する注意点：「FCPからTTI」は、Lighthouseのデフォルトのナビゲーション監査を具体的に指しています。他のツールや、完全なページ読み込みナビゲーションではなくタイムスパントレースを実行するLighthouse自体は、異なる測定ウィンドウを合計する場合があります — 50 msの長いタスクの計算は変わりませんが、合計される開始点と終了点はツールおよびトレースモード固有であり、指標の普遍的な法則ではありません。

TBTはCore Web Vitalsですか？いいえ。

これは最も一般的な誤解なので、はっきり言いましょう。3つのCore Web VitalsはLCP、INP、CLSです。TBTはそのうちの1つではありません。Google自身の表現：“Total Blocking Time (TBT) is a lab metrics is vital in catching and diagnosing potential interactivity issues that can impact INP. However, it is not part of the Core Web Vitals set because they are not field-measurable, nor do they reflect a user-centric outcome.” (翻訳) 「Total Blocking Time (TBT)は、INPに影響を与える可能性のある潜在的なインタラクティブ性の問題を発見および診断する上で重要なラボ指標です。ただし、フィールドで測定できず、ユーザー中心の結果を反映していないため、Core Web Vitalsセットの一部ではありません。」（その文の文法は彼らのものであり、私のものではありません。）

では、TBTはどこに表示され、どこに表示されないのでしょうか？

• 表示される場所: Lighthouse、 PageSpeed Insightsのラボタブ、Chrome DevTools — すべてシミュレーション/ラボ環境です。
• 表示されない場所: Google Search ConsoleのCore Web Vitalsレポート、CrUX、または フィールドデータ。これらはLCP、INP、CLSのみを保持します。

「Search ConsoleでTBTを見ている」と言う人がいたら、それは誤解です — GSCはフィールドデータを報告し、TBTはフィールド指標ではありません。

正確にしておくべき修正が1つあります: TBTがラボ推奨であることは、TBTがフィールド不可能であることと同じではありません。Long Tasks APIを使えば、技術的にはフィールドでTBTスタイルの合計を計算できます — Googleは直接そう述べています: “It is possible to measure TBT in the field, but we don’t recommend this as user interaction can affect your page’s TBT in ways that lead to lots of variance in your reports.” (翻訳) 「フィールドでTBTを測定することは可能ですが、ユーザー操作がページのTBTに影響を与え、レポートに大きなばらつきをもたらす可能性があるため、これは推奨しません。」 これは技術的な壁ではなく、それに対する推奨事項です。例外なく実際に正しいことは、より狭い範囲です: CrUXとSearch ConsoleのCore Web VitalsレポートはTBTを決して保持せず、完全に — それらのパイプラインはLCP、INP、CLSのみを収集します。

TBTはINPのラボプロキシ

TBTがそもそも存在する理由はここにあります。ラボツールは実際のユーザーがいないシミュレーション環境でページを読み込むため、Interaction to Next Paintを測定できません — INPには実際のクリックとタップが必要です。TBTはそのギャップを埋めます: “the Total Blocking Time (TBT) metric is lab-measurable and is a proxy for INP.” (翻訳) 「Total Blocking Time (TBT) メトリックはラボで測定可能であり、INPのプロキシです。」

この2つは機械的に関連しています: “Although INP and TBT are calculated differently, they are both reflections of a blocked main thread during the bootstrap process. When the main thread is blocked, the browser is delayed in responding to user interactions.” (翻訳) 「INPとTBTは計算方法が異なりますが、どちらもブートストラッププロセス中のメインスレッドのブロックを反映しています。メインスレッドがブロックされると、ブラウザはユーザー操作への応答が遅れます。」 そして経験的に、“A low TBT often correlates with a low Interaction to Next Paint (INP).” (翻訳) 「TBTが低いことは、多くの場合、Interaction to Next Paint (INP) の低さと相関します。」

しかし「プロキシ」は「代替」ではありません。Googleは明確に述べています: “Total Blocking Time (TBT) may be a reasonable proxy metric for INP, but it’s not a substitute for INP in and of itself.” (翻訳) 「Total Blocking Time (TBT) はINPの合理的なプロキシメトリックかもしれませんが、それ自体がINPの代替ではありません。」 それらは実際に乖離します:

• TBTが高く、INPは良好。 TBTは読み込み中のブロックを測定します。ユーザーがそのブロックされた時間帯に実際に操作しようとしない場合 — ページが完成して見えるまで待つ場合 — INPは悪いTBTでも良好になり得ます。
• TBTが良好で、INPが不良。 INPは、読み込み後に発生する遅いイベントハンドラやレンダリング処理、さらにモバイル向けに最適化されていないページで生じるブラウザの300 msのタップ遅延なども対象にします。これらはTBTでは捉えられません。

ラボとフィールドが一致しない場合は、フィールドを信頼してください。INP (実際のユーザー数値) はTBT (ラボ推定値) よりも優先されます。

人々を混乱させる歴史的なメモが1つあります: TBTはかつて**First Input Delay (FID)**のラボプロキシでした。INPは2024年3月12日にCore Web VitalとしてFIDに取って代わったため、TBTは現在INPのプロキシです。根本的なメカニズムは決して変わっていません — 常に読み込み中のメインスレッドのブロックに関するものでした — しかし、TBTを「FIDのプロキシ」と呼ぶ古い記事はすべて、その切り替えより前のものです。

TBTがLighthouseスコアを支配する理由

TBTは**Lighthouseパフォーマンススコアで最大の単一ウェイト — 30%**を占めます。このウェイトはLighthouse 10で導入され、2026-07-18にChromeのスコアリングドキュメントに対してライブで検証され、現在のLighthouse 13まで変更されていません:

その表はバージョンと日付にスコープされたものであり、恒久的な定数ではないと扱ってください — Lighthouseは以前にウェイトを変更したことがあり、再度変更する可能性があります。監査デッキで引用する前に、Lighthouse パフォーマンス スコアリング を参照して再検証してください。

これは、TBTがランキングシグナルではないにもかかわらず、SEO監査で重要になる実務上の理由です。TBTが悪いと、誰もがスクリーンショットを撮るLighthouseの大きなスコア値にひときわ強く影響します。Addy Osmaniの実例では、Intersection Observerのポリフィルを1つ削除しただけで、TBTが400 msから300 msに短縮され、Lighthouseのパフォーマンススコアが63から70に上がりました。1件の修正で7ポイント上昇したのは、TBTの重みが30%あるためです。

もう1つのニュアンス：「Good ≤200 ms」のカテゴリしきい値とLighthouseのスコアは異なる尺度です。TBTサブスコアで90以上を取るには、モバイルでおおよそ≤300 msが必要で、100を取るには≤100 msが必要です。(これらのサブスコアの数値は、DebugBearのスコアリングカーブのドキュメントに基づき、2026-07-18にライブソースに対して再検証済みです。)「Good」と「100」は同じ基準ではありません。

TBTはSEOランキングに影響しますか？

直接は影響しません。そして、私はほとんどの人よりも率直に言います。

TBTはランキングシグナルではありません。Googleのインタラクティブ性のランキング入力はINPであり、フィールド指標です。TBTは、INPを損なう長いタスクを見つけて修正するのに役立つ診断指標です。TBTを改善するとINPが改善される可能性があり、それが順位のPage Experience側にわずかに役立つかもしれません。しかし、それはあなたの順位から「かもしれない」が2つ離れています。

Core Web Vitals全体に対する私の実際の立場は、以前ページ速度ガイドで書いた とおりです。Core Web VitalsがSEOに大きな影響を与えるとは思いません。極端に遅い場合を除き、通常は優先しません。順位上昇のためではなく、ユーザーとコンバージョンのために改善してください。フィールド指標のラボ用プロキシであり、ランキングへの寄与も小さいTBTでは、なおさらです。順位を追うためではなく、フリーズしたページで顧客を失わないために直してください。

TBTが高くなる原因

ほとんどの場合、JavaScriptが原因です：

• 不要なJavaScriptの読み込み、解析、または実行 — Lighthouse監査の言葉そのものです。ページが読み込み時に必要としない大きなバンドルを配信することが典型的な原因です。
• 非効率なJavaScriptステートメント — メインスレッドを占有する重い同期処理。
• サードパーティスクリプト — タグマネージャー、チャットウィジェット、アナリティクス、広告スクリプト。多くの場合、最大の貢献要因であり、最も制御が効かないものです。
• 重いフレームワークのブートストラップ — Reactのハイドレーションなどは、起動中に長いタスクを実行できます。
• スタイル/レイアウトの再計算とガベージコレクション — 強制同期レイアウト、大規模なスタイル再計算、GCポーズもメインスレッドタスクとして表示されます。トレース内のすべての長いタスクがJavaScript実行であると想定しないでください。

バンドルの転送サイズがすべてだと思わないでください。トレースの属性には実際のギャップがあります。クロスオリジンフレームとワーカースレッドには、長いタスクオブザーバーがそれらについて報告できる内容にプライバシーとセキュリティの制限があります（トラブルシューティングを参照）。そのため、トレース内の属性なしタスクは、サードパーティが関与していない証拠ではありません。属性APIがそれを伝えることを許可されていないだけかもしれません。

高いTBTを修正する方法

修正方法はINPの修正と同じ系統です。どちらもメインスレッドのブロックに帰着します。

1. 長時間タスクを見つける。 Chrome DevTools の Performance パネルを開き、50 ms を超えるタスク（赤い角でマークされます）を探すか、Lighthouse の「Avoid long main-thread tasks」監査を実行します。
2. まずサードパーティスクリプトを監査する。 通常、これらが最も簡単な改善点です。DevTools の Coverage タブと Network タブを使用して各スクリプトのコストを確認し、重い埋め込み（YouTube、マップ、チャット）をファサードの背後で遅延読み込みします。
3. 長時間タスクを分割する。 メインスレッドに譲歩して、ブラウザがチャンク間で入力を処理できるようにします — 「タスクが分割されると、ブラウザはより優先度の高い作業（ユーザー操作を含む）にはるかに早く応答できます。」 最新の API は scheduler.yield() で、setTimeout(resolve, 0) のフォールバックがあります（パターンについては Cheat Sheets タブを参照）。Google は もはや isInputPending() を推奨していないことに注意してください — 入力が保留中かどうかに関係なく譲歩します。
4. JavaScript を削減する。 大きなバンドルをコード分割して読み込み時の解析と評価を減らし、未使用の JS を削除し（DevTools の Coverage タブで確認できます）、重要でないスクリプトには defer を使用します。
5. 重い計算をメインスレッドから移動する。 Web Workers は CPU 負荷の高い作業を別のスレッドで実行し、メインスレッドを応答可能な状態に保ちます。

便利な副作用: メインスレッドをブロックする長時間タスクは、Largest Contentful Paint のレンダリングも遅延させる可能性があるため、TBT を修正すると LCP も改善されることがあります — 特にレンダリングをブロックする JS が関与している場合です。

次に進む場所

TBT は Core Web Vitals ファミリーに属し、フィールド版の Interaction to Next Paint、読み込みメトリクスの Largest Contentful Paint と First Contentful Paint、およびそれらを報告するラボツールの Lighthouse、PageSpeed Insights、Speed Index と並んでいます。1 つだけ覚えておくなら: TBT は フィールド の応答性に対する ラボ の警告灯です — 数値ではなく長時間タスクを追いかけましょう。

AIまとめ

Advancedバージョンの簡潔な見解:

• TBT = 読み込み中のメインスレッドのブロック時間。 FCP から TTI までの間に、メインスレッドが入力応答を妨げるほど長くブロックされた合計時間です。
• 計算方法: 各長時間タスク（50 ms を超えるメインスレッドタスク）のブロック部分（duration − 50 ms）の合計。50 ms 以下のタスクは 0 ms を追加します。Google の計算例: 250/90/35/30/155 ms のタスク → 345 ms の TBT。
• ラボメトリクスです。 Lighthouse、PageSpeed Insights のラボタブ、DevTools で確認できます — CrUX や Search Console では 決して 確認できません。
• Core Web Vitals ではありません。 3 つの CWV は LCP、INP、CLS です。TBT は INP のラボプロキシ です（歴史的には FID のプロキシでした。INP は 2024 年 3 月 12 日に FID を置き換えました）。
• Lighthouse で最大の重み: 30% — 単独で最大のため、TBTが悪いと全体スコアが低下します。モバイルのしきい値は、良好が≤200 ms、改善が必要が≤600 ms、不良が

  600 msです。

• ランキング: 直接のランキング要因ではありません。INP がフィールドシグナルであり、TBT はその診断に役立つだけです。Patrick の見解: ランキング向上のためではなく、ユーザーとコンバージョンのために修正しましょう。
• 修正方法（INP と同じファミリー）: DevTools で長時間タスクを見つけ、まずサードパーティスクリプトを監査し、scheduler.yield() でタスクを分割し、コード分割と未使用 JS の削除、重い作業を Web Workers にオフロードします。
• 注意点: TBT と INP は乖離することがあります — TBT が高くても INP が良好（ユーザーが読み込み中に操作しない）または TBT が良好でも INP が不良（読み込み後のイベントハンドラが遅い）場合があります。フィールドデータが優先されます。
• 「ラボのみ」はラボ推奨であり、ラボ不可能ではありません。 技術的には Long Tasks API を使用してフィールドデータから TBT スタイルの合計を計算できますが、Google はそれに反対しています（実行ごとのばらつきが大きすぎるため）— CrUX と Search Console はどちらにせよそれを単に保持しません。
• トレース属性には実際のギャップがあります。 クロスオリジンフレームとワーカースレッドには、長時間タスクオブザーバーが報告できる内容にプライバシー/セキュリティ上の制限があるため、属性なしのタスクは「原因不明」を意味し、「サードパーティが関与していない」ことを意味しません。

公式ドキュメント

Google と Chrome チームによる TBT に関する一次情報のドキュメント。

web.dev / Chrome

• Total Blocking Time (TBT) — Philip Walton と Barry Pollard による、標準的な定義、50 ms の長いタスクのルール、および計算例。
• TBT Lighthouse audit — 監査ページ。モバイル/デスクトップのスコアリングしきい値と、引用された原因が記載されています。
• Lighthouse performance scoring — メトリクスの重み。TBT の 30% がここから来ています。
• Web Vitals — TBT が Core Web Vital ではない理由と、そのセットとの関係。
• Interaction to Next Paint (INP) — TBT が代理するフィールドメトリクス、および「代理であり、代替ではない」という注意点。
• Optimize long tasks — Jeremy Wagner と Brendan Kenny による、タスクの分割、scheduler.yield()、および isInputPending() が推奨されなくなった理由について。
• Time to Interactive (TTI) — TBT ウィンドウの終了を定義するメトリクス、および Lighthouse 10 で削除された理由。
• ラボデータとフィールドデータの違い — INPの代用としてTBTを使う際の限界。

ソースからの引用

Google のドキュメントからの公式な声明。各リンクは、引用した箇所にジャンプするディープリンクです。

定義と仕組み

• “the total amount of time after First Contentful Paint (FCP) where the main thread was blocked for long enough to prevent input responsiveness.” (翻訳) 「First Contentful Paint (FCP) の後、メインスレッドが入力応答性を妨げるほど長くブロックされた合計時間。」 — web.dev、Total Blocking Time。 引用にジャンプ
• “a task that runs on the main thread for more than 50 milliseconds” (翻訳) 「メインスレッドで50ミリ秒を超えて実行されるタスク」— 長いタスクの定義。 引用にジャンプ
• “To provide a good user experience, sites should strive to have a Total Blocking Time of less than 200 milliseconds when tested on average mobile hardware.” (翻訳) 「良好なユーザーエクスペリエンスを提供するには、サイトは平均的なモバイルハードウェアでテストしたときに、Total Blocking Time を 200 ミリ秒未満にするよう努めるべきです。」 引用にジャンプ
• “A low TBT often correlates with a low Interaction to Next Paint (INP).” (翻訳) 「TBT が低いことは、多くの場合、Interaction to Next Paint (INP) が低いことと相関します。」 引用にジャンプ

ステータス: Core Web Vital ではない

• “Total Blocking Time (TBT) is a lab metrics is vital in catching and diagnosing potential interactivity issues that can impact INP. However, it is not part of the Core Web Vitals set because they are not field-measurable, nor do they reflect a user-centric outcome.” (翻訳) 「Total Blocking Time (TBT) は、INP に影響を与える可能性のある潜在的なインタラクティブ性の問題を検出および診断する上で重要なラボメトリクスです。ただし、フィールドで測定できず、ユーザー中心の成果を反映していないため、Core Web Vitals セットの一部ではありません。」 — web.dev、Web Vitals (Philip Walton)。(文法はソースからそのまま引用しています。) 引用にジャンプ

INP の代理としての TBT

• “In such cases, Total Blocking Time (TBT) may be a reasonable proxy metric for INP, but it’s not a substitute for INP in and of itself.” (翻訳) 「そのような場合、Total Blocking Time (TBT) は INP の合理的な代理メトリクスとなる可能性がありますが、それ自体が INP の代替ではありません。」 — web.dev、Interaction to Next Paint。 引用にジャンプ

長いタスクとその修正

• “The main thread can only process one task at a time. Any task that takes longer than 50 milliseconds is a long task.” (翻訳) 「メインスレッドは一度に1つのタスクしか処理できません。50ミリ秒を超えるタスクはすべて長いタスクです。」 — web.dev、長いタスクの最適化。 引用にジャンプ
• “When tasks are broken up, the browser can respond to higher-priority work much sooner—including user interactions.” (翻訳) 「タスクが分割されると、ブラウザはユーザー操作を含む優先度の高い作業にはるかに早く応答できます。」 引用にジャンプ
• isInputPending()について: “We no longer recommend using this API, and instead recommend yielding regardless of whether input is pending or not.” (翻訳) 「このAPIの使用は推奨しなくなりました。代わりに、入力が保留中かどうかに関係なく、処理を譲ることを推奨します。」 引用にジャンプ

TTIと、主要なインタラクティブ指標としてTBTがTTIに取って代わった理由

• “Newer, alternative, metrics like Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Interaction to Next Paint (INP) are usually better metrics to use in place of TTI.” (翻訳) 「Largest Contentful Paint (LCP)、Total Blocking Time (TBT)、Interaction to Next Paint (INP)などの新しい代替指標は、通常、TTIの代わりに使用するのに適した指標です。」 — web.dev、Time to Interactive (Philip Walton)。 引用にジャンプ

TBTトリアージチェックリスト

Lighthouseが赤（またはオレンジ）のTotal Blocking Timeを表示したときの簡単なチェック:

• ラボデータを確認していることを確認する — TBTはLighthouse / PageSpeed Insightsのラボタブ / DevToolsにあり、フィールドやSearch Consoleにはありません。
• DevToolsのパフォーマンスパネルを開き、最初の描画からインタラクティブまでの間にある長いタスク（50ミリ秒超、赤い角）を見つけます。
• サードパーティスクリプトとそれぞれのコスト（カバレッジ + ネットワークタブ）をリストアップする — ここから始めましょう。通常、最大かつ最も簡単な改善点です。
• 重い埋め込み（YouTube、マップ、チャット）をファサードの背後で遅延読み込みします。
• Lighthouseの**「長いメインスレッドタスクを回避」および「未使用のJavaScriptを削減」**監査を実行し、リストに取り組みます。
• 大きなバンドルをコード分割して、読み込み時に解析/評価されるJSを減らします。
• 重要でないスクリプトを遅延させ、すぐに必要ないものは動的import()します。
• 残りの長いタスクを scheduler.yield() （setTimeoutフォールバック）で分割します。isInputPending()には手を出さないでください。
• CPU負荷の高い計算をWeb Workerに移します。
• フィールドをクロスチェックする: CrUX / 実ユーザーモニタリングからINPを取得します。INPが問題なければ、ラボの数値を追いかけるのに過度に投資しないでください。

TBTチートシート

計算式、一行で

TBT = Σ (taskDuration − 50 ms) は、FCPとTTIの間にある > 50 ms の各タスクについて計算します。≤ 50 ms のタスクが加算する値は 0 ms です。

計算例（Googleのもの）

Lighthouseのしきい値

（しきい値はLighthouseのサブスコア曲線とは異なります: 90以上 ≈ モバイルで≤300 ms、100 ≈ モバイルで≤100 ms — DebugBearの文書化された数値で、2026-07-18にライブで再検証済み。）

TBT vs. INP — チートシート

Yield-to-mainパターン（修正方法）

function yieldToMain () {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

利用可能な場合はscheduler.yield()を使用し、フォールバックとしてsetTimeoutを使用します。isInputPending()は使用しないでください。Googleは現在、入力が保留中かどうかに関係なく、yieldすることを推奨しています。

TBTの測定と修正のためのツール

• PageSpeed Insights — ラボデータセクションでTBTを確認します（TBTはフィールド指標ではないため、フィールドデータセクションにはありません）。
• Lighthouse（Chrome DevTools → Lighthouseパネル、またはCLI）— TBT数値のソースであり、「長いメインスレッドタスクを回避」/「未使用のJavaScriptを削減」の監査のソースです。
• Chrome DevTools — Performanceパネル — 読み込みを記録し、TBTを構成する長いタスク（50ミリ秒超、赤いコーナーでフラグ付け）を見つけます。
• Chrome DevTools — Coverageタブ — 各スクリプトが実際にどの程度使用されているかを確認し、未使用のJavaScriptや重いサードパーティを特定します。
• WebPageTest — 詳細なメインスレッドとCPUの内訳を含むラボテスト。
• Long Animation Frames (LoAF) API — TBTのモダンなフィールド側の補完であり、ラボの読み込みウィンドウ計算の代替ではありません。訪問全体にわたる長いアニメーションフレームを属性付けし、TBTの単一のFCPからTTIまでの読み込みウィンドウではなく、INPの問題が実際に表面化する方法に近いものです。
• Long Tasks APIによるフィールド側のTBT — 技術的には可能です（本番環境で観測された長いタスクのduration − 50 msを合計します。Scriptsタブのスニペットと同じです）が、GoogleはRUMでの使用を推奨していません。実際のユーザー操作のタイミングにより、数値が変動しすぎて実行ごとの比較ができません。フィールドの応答性にはINPまたはLoAFを使用してください。
• 確認できない場所: Google Search ConsoleのCore Web VitalsレポートとCrUXには、LCP、INP、CLSのみが含まれます。技術的に自分で計算できるかどうかに関係なく、TBTは含まれません。

誤った修正につながるTBTの間違い

• TBTをCore Web Vitalと呼ぶこと。 TBTはラボ診断であり、メインスレッドの競合の有用なプロキシです。INPは実際のユーザーのCore Web Vitalです。これらは別々に報告してください。
• 長いタスク全体をブロッキング時間として数えること。 50ミリ秒を超える部分のみがカウントされます。70ミリ秒のタスクは、70ではなく20ミリ秒を貢献します。
• 測定ウィンドウの外で最適化すること。 Lighthouse TBTは、FCPとTTIの間のブロッキングを合計します。このウィンドウの前後の作業はユーザーにとって重要かもしれませんが、そのTBT値の一部ではありません。
• 最大のサードパーティを無視しながらファーストパーティコードを削除すること。 トレースとリクエストイニシエーターを使用して、所有者または修正を選択する前に長いタスクを属性付けしてください。
• 作業を減らさずにコードを分割すること。 多くの小さなタスクは応答性を向上させることができますが、同じ不要なJavaScriptを配信すると、解析、コンパイル、実行のコストが依然としてかかります。未使用の作業を削除し、yieldも行ってください。
• 良好なラボTBTが良好なフィールドINPを証明すると仮定すること。 実際のユーザーは、さまざまなデバイスで読み込み後に操作します。フィールドの応答性データで結果を確認してください。

TBTは高いがネットワークは速く見える

症状: リソースは迅速にダウンロードされるが、Lighthouseは重いブロッキングを報告する。

考えられる原因: JavaScriptの解析、コンパイル、実行、ハイドレーション、またはサードパーティの作業が、バイトが到着した後にメインスレッドを独占している。

修正と確認: Performanceトレースを記録し、長いタスクを期間と所有者で並べ替え、未使用のコードを削除するか、重要でない作業を遅延させるか、最大のタスクを分割します。ブロッキング部分が繰り返しの一致する実行で低下することを確認します。

大きなバンドルが遅延されているがTBTは高いまま

症状: defer を追加するとダウンロード/実行順序が変わるが、TBT は実質的に変わらない。

考えられる原因: 同じ高コストなコードが依然として FCP から TTI のウィンドウ内で実行されている。

修正と確認: 長時間タスク内の関数をプロファイリングする。ルートまたはインタラクションごとにコード分割し、ハイドレーションを減らすか、未使用・重複した処理を削除する。その後、リクエスト開始時間だけでなく実行時間が減少することを確認する。

Lighthouse TBT は良好だが、フィールド INP が悪い

症状: ナビゲーションのラボテストはレスポンシブに見えるが、CrUX や RUM は遅いインタラクションを報告する。

考えられる原因: 問題のあるタスクが初期ロード後、または標準の Lighthouse ナビゲーションが実行しない実際のインタラクション後にのみ発生する。

修正と確認: INP が悪いページとデバイスでインタラクショントレースを収集し、その操作をローカルで再現して、イベント処理と次のペイントを最適化する。

明確な所有者がいない長時間タスク

症状: DevTools または Long Tasks API オブザーバーがブロッキングタスクをフラグするが、属性情報が空白、一般的、または「unknown」/「cross-origin」のようなラベルになっている。

考えられる原因: これは測定エラーではなく、既知のカバレッジ上の制約です。Long Tasks APIの仕様自体が、実行コンテキストをまたいで報告できる範囲を限定しています。クロスオリジンの祖先タスクは意図的に報告されず、仕様には “this is not reported because of security” (翻訳) 「これはセキュリティ上の理由で報告されない」とあります。また、深く埋め込まれたクロスオリジンiframeは、クロスオリジンの祖先で発生したロングタスクについて “does not receive any information” (翻訳) 「いかなる情報も受け取らない」とされています。Web Workerやブラウザのコンポジタスレッドで実行される処理も、表示される帰属情報の範囲外になることがあります。

修正と確認: 何も名前が挙がっていないからといって「サードパーティは関与していない」と結論付けない。ネットワークパネルのイニシエーター列、カバレッジタブ、そして（スクリプトを制御している場合）所有する iframe 内のファーストパーティ計測と照合する。属性情報がないタスクは「原因不明」として扱い、「原因なし」とはしない。

TBT が実行間で大きく変動する

症状: デプロイがないのに、ある実行は良好で次の実行は悪い。

考えられる原因: 変動するサードパーティの実行、作業ウィンドウを変えるサーバータイミング、キャッシュ状態、またはテストマシンの競合。

修正と確認: 設定を一致させ、複数回のコールドテストを実行し、単一のスコアを選ぶのではなく、長時間タスクの所有者と中央値を比較する。

トレースを所有権計画に変える

Review this Lighthouse/DevTools trace for Total Blocking Time. For every long task
between FCP and TTI, calculate only duration above 50 ms as blocking time, attribute
the task to first-party code, framework/hydration, or a named third party, and rank
owners by blocking contribution. Propose remove, reduce, defer, split, or yield actions
with a validation test for each. Do not treat TBT as field INP or a direct ranking
factor.

2 つのパフォーマンストレースを比較する

Compare these before/after traces under matched settings. Report FCP, TBT, the largest
long tasks, their initiators, and whether work moved outside the measurement window or
was actually removed. Flag regressions hidden by the aggregate score. Return a verdict,
confidence limits from the supplied runs, and the next smallest experiment. Do not
invent missing timings.

サードパーティスクリプトの決定をレビューする

Given this script's business purpose, loading pattern, request initiator, and main-
thread tasks, decide whether to keep, delay, conditionally load, replace, or remove it.
Separate network cost from execution/blocking cost. Include consent and functionality
constraints, owner, implementation step, TBT validation, field-INP follow-up, and
rollback trigger.

再現中に長時間タスクを観察する

これを DevTools コンソールで早めに実行し、ロードまたはインタラクションを再現して、各タスクのブロッキング部分を検査する:

let observedBlocking = 0;
const observer = new PerformanceObserver(list => {
  for (const task of list.getEntries()) {
    const blocking = Math.max(0, task.duration - 50);
    observedBlocking += blocking;
    console.log({ start: task.startTime, duration: task.duration, blocking });
  }
  console.log('Observed blocking total:', observedBlocking);
});
observer.observe({ type: 'longtask', buffered: true });

これは観察期間中のデバッグ合計であり、同じ FCP から TTI のウィンドウとテスト条件を意図的に再現しない限り、Lighthouse の公式 TBT ではない。

メインスレッドの評価時間が最も長いスクリプトをフラグする

DevTools パフォーマンストレースを記録した後、URL でグループ化した Bottom-up ビューを使用する。それに加えて簡単なネットワークインベントリとして、このコンソールスニペットは転送された JavaScript を大きい順にリストする:

performance.getEntriesByType('resource')
  .filter(r => r.initiatorType === 'script')
  .map(r => ({ script: r.name, transferred: r.transferSize, duration: r.duration }))
  .sort((a, b) => b.transferred - a.transferred);

転送サイズが大きいことは手がかりに過ぎない。解析と実行時間を TBT に帰属させるのはパフォーマンストレースである。

長時間タスクの削減

実行するテスト: JavaScript の変更前後で、一致する Lighthouse/パフォーマンストレースを複数回取得し、FCP と TTI の間の長時間タスクを比較する。

期待される結果: 対象のタスクが消える、短くなる、またはより小さなタスクに分割され、FCP を遅らせたり機能を壊したりせずに TBT の中央値が改善する。

失敗の解釈: 処理が別のバンドル/タスクに移動した、同じウィンドウ内でまだ実行されている、または通常の実行ばらつきが変更よりも大きい。

監視ウィンドウ: モバイルとデスクトップのラボプロファイルで直ちにテストし、次のレポートウィンドウでフィールド INP を監視する。

ロールバックのトリガー: 重要なインタラクションが壊れる、エラーが増加する、または再現可能な FCP/LCP/INP の回帰が TBT の改善を上回る場合はロールバックする。

サードパーティの遅延

実行するテスト: サードパーティを現在の位置に置いた場合と、同意、アイドル時間、または関連する操作まで遅延させた場合のコールドトレースを比較します。

期待される結果: そのロングタスクが初期TBTウィンドウから外れ、必要なビジネスイベントが意図したタイミングで引き続き発生します。

失敗の解釈: 別のローダーがそれを早期に注入する、依存コードがページをブロックする、またはスクリプトのメインスレッド作業が測定されたボトルネックではない。

監視ウィンドウ: スクリプトを読み込むすべてのテンプレートで検証し、リリース後にパフォーマンスとビジネスイベントの両方を監視します。

ロールバックトリガー: 同意、アナリティクス、チェックアウト、広告、またはその他の必須機能が有効なイベントを失った場合は、以前の読み込みパスを復元します。

フィールド応答性のフォローアップ

実行するテスト: ラボのTBT変更後、影響を受けるテンプレート/デバイスでフィールドINPをセグメント化し、デプロイ日を注釈として残します。

期待される結果: フィールド応答性が安定または改善する。ラボのみの改善は、フィールドの証拠がそれを裏付けるまでユーザー成果として報告されない。

失敗の解釈: 実際のインタラクション作業が初期読み込み外で発生するか、最適化されたコホートが小さすぎて全体を動かせない。

監視ウィンドウ: 完全なフィールドデータレポートウィンドウと高価値インタラクション中にレビューします。

ロールバックトリガー: リリース後にフィールドINPまたは重要なインタラクションの成功が一貫して悪化する場合は調査またはロールバックします。

自分でテスト: 総ブロッキング時間

TBTの計算と診断に関する5つの簡単な質問。各質問に回答を選び、確認してください。

時間をかける価値のあるリソース

公式

• Total Blocking Time (TBT) — 標準的な定義と計算例。
• Optimize long tasks — 実践的な修正ガイド（scheduler.yield()、バッチ処理、isInputPending()が不適切な理由）。
• Web Vitals — TBTがCore Web Vitalsの中でどこに位置するか。
• Optimizing Web Vitals using Lighthouse — Addy Osmani著。ポリフィル削除の実例（TBT 400→300 ms、スコア63→70）を含む。

他からの情報（引用前に検証）

• DebugBear — Total Blocking Time — TBT↔INPのメカニズムとLighthouseスコアリング曲線に関する高度な技術的深さ。
• NitroPack — What is Total Blocking Time? — 「タスク数≠ブロッキング時間」の洞察。
• BrowserStack — TBTガイド および Catchpoint — TBT — ツール/監視向けの概要。
• web.dev — User-centric performance metrics — Philip Waltonのフレームワークで、TBTをラボ/読み込み応答性メトリクスとして分類し、フィールドメトリクスと対比。TBTがCrUXに表示されない理由を説明するのに有用。
• web.dev — Web Vitals測定入門 — シミュレーション環境で実ユーザー測定ができない場合に、TBTがINPのラボ用プロキシとして機能する仕組みを説明しています。
• WebPageTest — TBTを詳細なメインスレッドおよびCPU内訳とともに報告する無料のラボテストツール。高いスコアを引き起こすタスクの診断に有用。
• Search Engine Journal — Core Web Vitals coverage — CWVアップデート、監査におけるTBTの役割、実務者がラボとフィールドのギャップを解釈する方法に関する継続的な業界レポート。

引用に値する統計

• TBTはLighthouseパフォーマンススコアの30%を占める — これは全メトリクスの中で最大の重みです（LCPとCLSはそれぞれ25%、FCPとSpeed Indexはそれぞれ10%）。Lighthouse 10で導入され、2026-07-18にLighthouse 13まで変更がないことを再確認済みです。 ソース
• 「良好」の基準はモバイルで200 ms以下（デスクトップでは150 ms以下）、「不良」はモバイルで600 ms超（デスクトップでは350 ms超）— Lighthouse監査ドキュメントより。 ソース
• ポリフィル1つで7ポイントの差。 単一のIntersection Observerポリフィルを削除することで、TBTが400 msから300 msに短縮され、Lighthouseパフォーマンススコアが63から70に向上しました — 30%の重みを明確に示す例です。 ソース
• 250 msのタスクは200 msのブロッキング時間に寄与する — ブロッキング部分は常に duration − 50 ms です。Googleの計算例では、5つのタスクで合計345 msになります。 ソース

変更履歴