TBT(Total Blocking Time)とは?仕組みから計測方法まで徹底解説

TBT(Total Blocking Time)とは?仕組みから計測方法まで徹底解説

このページではTBT(Total Blocking Time)についてわかりやすく解説していきます。

計測される仕組みから、評価内容までを解説していきます。

TBTの改善方法を知りたい方は「TBTの6つの改善施策」の記事をご覧ください。

TBT(Total Blocking Time)とは?

TBT(Total Blocking Time)は、ユーザーがWebページにアクセスしてから「実際に操作できるようになるまでの時間」を測定する指標です。

FCP(初回コンテンツ表示)からTTI(操作可能時間)※になるまでの間に発生するタスクがメインスレッドをふさぐ合計時間です。

要はユーザーがページを操作できない時間を数値化するものです。

TBTの時間が短いと、ユーザー体験もよくなり評価が高いとみなされ、TBTの時間が長いと評価が低いという判断になります。

FCPについてわからないという方は「FCPとは」の記事を確認してみてください。

※TTIはLighthouse 10以降レポート指標からは削除されましたが、TBTの集計窓口の説明としてFCP→TTIが用いられています。

メインスレッドとブロッキングの概念を把握しておこう

Webブラウザには「メインスレッド」という、重要な処理を担当する部分があります。

このメインスレッドは、画面の描画、JavaScript の実行、ユーザーの操作への反応などを担当しています。

メインスレッドが何らかの処理(JavaScriptの実行など)で忙しくなると、ユーザーの操作に反応できなくなります。この状態を「ブロックされた」と表現します。

TBTでは、50ミリ秒以上メインスレッドがブロックされた場合に、その時間を「問題のある時間」として計算に含めています。

TBTのスコア算出の仕組み

TBTの計算は、FCP(初回コンテンツ表示)からTTI(操作可能時間)までの間に発生する複数のタスクにおいて、50ミリ秒を超えた時間の合計の数値がTBTのスコアになります。

TBTの計算式は下記となります。

TBT = (タスクAの実行時間 – 50ms) + (タスクBの実行時間 – 50ms) + (タスクCの実行時間 – 50ms)

TBTスコアに該当する計算の条件

  1. 各タスクの実行時間が50ミリ秒を超えている分が対象
  2. 超えている場合は、「実行時間 – 50ミリ秒」を計算
  3. すべてのタスクの超過時間を合計

TBTスコアの計算の際は、全てのタスクがTBTスコアに算出されるわけではありません。

上記の条件のように1つのタスクが50ミリ秒を超えた分を全て合算した数値がTBTスコアとなります。

図でわかりやすく解説すると下記のようになります。

図を元に解説すると、タスクの青い部分は50ミリ秒以下で、オレンジ色の部分は50ミリ秒を超えた秒数の部分となります。

それぞれのタスク計算は下記となります。

  • タスク1は40ミリ秒(50ミリ秒以下なので対象外)
  • タスク2は70ミリ秒(70 – 50 = 20ミリ秒が対象)
  • タスク3は120ミリ秒(120 – 50 = 70ミリ秒が対象)
  • タスク4は50ミリ秒(50ミリ秒以下なので対象外)
  • タスク5は100ミリ秒(100 – 50 = 50ミリ秒が対象)

この場合のTBTの計算は下記となります。

0 (タスク1)+ 20(タスク2)+ 70(タスク1)+ 0(タスク1)+ 50(タスク1)= 140ミリ秒

TBTの重要性について

TBT時間が長いということは、クリックやフォーム入力といった操作ができないため、ユーザーにストレスがかかるということになります。

TBTの数値が悪いとユーザー体験も悪くなり、サイトへの信用度なども失われやすくなりますし、サイトの離脱率や直帰率が上がる原因にもなります。

ユーザー体験にも大きく影響する指標であるということは理解しておきましょう。

Core Web VitalsのINPの指標にも影響

TBTはCore Web Vitalsの指標であるINPの指標に対しての影響があります。

INPは、ユーザーが操作したときに、ブラウザが画面に反応するまでの時間を測る指標です。

そのため、TBTの数値が改善されることでINPの数値も改善されるということになります。

INPについては「INPとは」の記事もご覧ください。

PageSpeed Insightsでも採用されている

TBTはPageSpeed Insightsでも採用されている指標となります。

こういった指標があるということは、googleも数値の悪いサイトへの改善を求めていると考えられるでしょう。

Core Web VitalsのINPへの影響なども考えるとSEO評価への影響もあると考えておくべきです。

直帰率とコンバージョンへの影響

TBTが長い状況では、ユーザーは「サイトが重い」「反応が悪い」と感じ、他の競合サイトへ移動する可能性が高くなります。

これにより直帰率が上昇し、結果的にコンバージョン率の低下にもつながります。

eコマースサイトの場合、商品ページでの操作遅延は直接的に売上機会の損失となるため、特に注意が必要です。

TBTの評価の目安となる数値

PageSpeed InsightsでのTBTスコアは、以下の基準で評価されます。

数値が低いほど良好となり、数値が高いほど問題があるということなります。

TBT数値

評価

表示色

説明

0~200ms

良好(Good)

緑色

ユーザーが快適に操作できる理想的な状態。ページの応答性が優秀で、クリックやタップに即座に反応する。SEOやUXの観点からも最適なレベル。

200~600ms

改善要(Needs Improvement)

オレンジ色

操作時に若干の遅延を感じる可能性がある。ユーザーエクスペリエンスに軽微な影響があり、改善の余地がある状態。優先的に対策を検討すべき。

600ms以上

不良(Poor)

赤色

ユーザーの操作に明らかな遅延が発生し、ストレスを与える状態。離脱率の増加やコンバージョン率の低下が懸念される。緊急に改善が必要。

googleはTBTスコアが200ミリ秒以下を推奨しています。

これを一つの目標としておくといいでしょう。

TBTの測定方法と分析ツール

TBTの計測方法についてご紹介していきます。

基本的にはPageSpeed Insights、lighthouseを活用する方法があります。

WEBサイトの表示速度を計測する方法でも詳しく説明しています。

PageSpeed InsightsでのTBT確認方法

PageSpeed InsightsにアクセスしURLを入力し分析ボタンをクリックするだけで計測が行われます。

手順としては下記の手順で分析ができます。

  1. PageSpeed Insightsにアクセス
  2. 分析したいURLを入力
  3. 「分析」ボタンをクリック
  4. パフォーマンスの箇所で結果を確認

計測に1分前後ほど待つ場合がありますが、計測結果や改善点も詳しく表示されます。

計測された後に、ややスクロールをするとパフォーマンスの画面が表示されます。

パフォーマンスの部分の画像でTBT計測結果が表示されます。

また、更に下部へスクロールしていくと結果の詳細の枠が出てきます。

ここで下記の画像のようにTBTという箇所をクリックすると、TBTに関わる部分の結果の詳細がわかるようになります。

PageSpeed Insightsでの計測の特徴は、下記のような点が挙げられます。

  • URL入力だけで簡単に確認できる
  • 1度の計測でモバイル・PC両方簡単に確認できる
  • 実際の利用環境での計測値になる
  • Chromeユーザーの実測値を集計
  • 改善ポイントなどが詳しく出てくる

特に実際の利用環境での計測値になる。という点はしっかり覚えておきましょう。

利用環境というのは、インターネット環境なども影響するためサイト以外の環境が影響するということになります。

ですので、開発環境以外でどう評価されるかなど確認する上でも良いツールとなります。

LighthouseでのTBT確認方法

開発者向けのより詳細な分析には、Lighthouseがおすすめです。

Lighthouseの計測方法として下記の手順に沿って計測ができます。

  1. Chromeで計測したいページを開く
  2. 右クリックして「検証」をクリック
  3. 「Lighthouse」タブをクリック
  4. 測定条件を設定する
  5. Analyze page loadをクリックして計測開始

上記の手順に沿って計測をスタートさせると、下記の画像のような計測結果の画面に切り替わります。

下記のパフォーマンスの画面ではTBTの結果がわかります。

更にスクロールしていくと、下記の画像のように詳細も確認ができます。

TBTのよくある質問

Q1: TBTを改善したのに、実際のユーザー体験が改善されない

A: TBTはラボデータ(模擬環境でのテスト)での測定値です。実際のユーザー環境では、ネットワーク速度やデバイス性能が異なるため、体感速度に差が生じることがあります。

Q2: 改善施策を実装したら、サイトの機能が動かなくなった

A: JavaScriptの最適化やサードパーティスクリプトの変更は、機能に影響を与える可能性があります。本番環境に適用する前に、必ずテスト環境で動作確認を行いましょう。また、段階的な実装により、問題の発生箇所を特定しやすくなります。

Q3: TBTは改善されたが、他の指標が悪化した

A: Webサイトの最適化では、トレードオフが発生することがあります。例えば、JavaScriptを削除してTBTを改善しても、必要な機能が動かなくなる可能性があります。全体的なバランスを考えて最適化を行いましょう。

Q4: モバイルのTBTだけが悪い

A: モバイル端末はCPU性能が低いため、同じコードでもデスクトップより実行時間が長くなります。モバイル向けには、より積極的な最適化が必要です。必要に応じて、モバイル専用の軽量版ページを作成することも検討しましょう。

まとめ

Total Blocking Time(TBT)の改善は、単なる技術的な指標の向上ではありません。

ユーザー体験の向上、SEOランキングの改善、そして最終的にはビジネス成果の向上に直結する重要な取り組みです。

下記のようにポジティブな面が多々あります。

  1. ユーザー体験の向上
  2. SEO効果
  3. コンバージョン率の向上
  4. 売上・収益の向上

TBTの改善は、技術的な知識がなくても始められる施策から、専門的な最適化まで幅広いアプローチが可能です。

まずは簡単にできることから始めて、段階的に改善を進めていきましょう。

記事を書いた人

井上寛生

井上寛生

LandingHub 執行役員 / 事業責任者 / 技術責任者

大学院では情報工学を専攻し、修了後に株式会社TeNへ新卒入社。当時は社内唯一のエンジニアながら、開発部門をゼロから立ち上げ、採用・育成を一手に担い、全員が未経験からスタートした精鋭エンジニアチームを組成。2021 年にはWEBサイト高速化プラットフォーム「LandingHub」を立ち上げ、プロダクトオーナー兼事業責任者として企画・開発・グロースを牽引。現在は執行役員として、会社の技術戦略と事業成長の双方をリードしている。
コラム一覧に戻る