TBT（Total Blocking Time）とは何か ─ "操作できない時間"が生まれる理由と改善の核心
PageSpeed Insights を見て「TBT が悪いと言われても、何を直せばいいのかわからない」というケースは少なくありません。
TBT（Total Blocking Time）は、ユーザーがサイトを"操作できない時間"を計測する指標 です。画面は見えているのに、次のような「固まっているような時間」が長いほど、TBT は悪化します。
- スクロールできない
- ボタンが押せない
- 入力ができない
Speed Index が"見た目の速さ"を評価する一方で、TBT は"触れるまでの速さ"を評価する指標です。今回は、TBT が悪化する理由と、その本質的な改善アプローチを解説します。
TBT が悪化するのは、ほぼ JavaScript が原因
TBT の数値は、次の式で決まります（過去発信していた情報より、現在は正しくない可能性があります）。
Long Task（50ms を超える処理）が実行されている時間の合計
つまり、ブラウザが「重い JavaScript の処理に捕まっている時間」をそのままスコアに反映しているのです。
代表的な Long Task の要因は以下です。
- 巨大な JavaScript ライブラリ
- 未使用の機能を含んだまま読み込んでいるケース。
- DOM 操作の多用
- 複雑な UI を初期化する JavaScript が一度に実行される。
- 初期化処理の集中
- カルーセル、アコーディオン、タブ、フェード演出などがLCP より前にすべて動き始めている。
- サードパーティースクリプト
- 特に広告・タグマネージャー・計測ツールなど。
TBT を改善するには、"何を後回しにできるか"が最重要
TBT の改善は、「不要な JavaScript を削る」よりも「必要な処理の実行時点をずらす」方が効果が大きいという特徴があります。
具体的には以下の方針が有効です：
- 初期表示に不要な JavaScript は defer / async へ移動
-
- LCP 要素とは関係ない処理
- スクロール後にしか使わない機能
- ユーザー操作があるまで動かない UI
- UI コンポーネントの初期化は LCP の後に回す
- カルーセルやアニメーションなどはユーザーが画面を見られる状態になってから初期化すべきです。
window.addEventListener('load', () => { initializeCarousel(); });
このように"表示後実行"へ移すだけでTBT が劇的に改善する例は多くあります。 - DOM 操作をまとめる（細かい操作を分散しない）
- JavaScript が最も重くなるパターンは、「小さな処理を大量に繰り返す」ことです。
- ループごとに DOM を書き換える
- 要素を1つずつ追加する
- 計算と描画が混在している
- サードパーティの読み込みを見直す
-
- タグマネージャー経由のスクリプトが多すぎる
- 広告タグが重い
- ABテストツールが初期化に時間がかかる
Speed Index と TBT を同時に改善できるポイント
Speed Index は「見た目が出るまで」、TBT は「触れるまで」。
この2つは別指標に見えますが、実は共通して改善できる部分があります。
- ファーストビューに必要な機能だけ残す
- 初期 JavaScript を最小限にする
- UI の初期化タイミングを後ろにずらす
特に JavaScript の扱い方はSpeed Index と TBT の両方に直結する"最重要ポイント"です。
"見えているのに動かない"をなくすことが TBT 改善の本質
TBT が悪いサイトに共通するのは、「画面は出ているのに、操作できない」という"体感ストレス"が存在することです。
これは単なる速度ではなく、ユーザー体験の質そのもの を左右する要素です。
操作ストレスのないサイトは、離脱を減らし成果に直結する
TBT を改善すると、次のような「触り心地の良さ」が向上します。
- スムーズにスクロールできる
- ボタンがすぐ反応する
- 入力が引っかからない
サイトの重さは、ページの出来栄え以上に ユーザーの印象を大きく左右します。あなたのサイトの操作感が少しでも重いと感じるなら、その裏には必ず"改善できる余地"があります。
※当記事はWebの間コーポレート記事の転載です。元記事はこちら。