Googleが検索上、重要視している指標が、コアウェブバイタルです。

コアウェブバイタルとは、Googleが設定している重要指標のうち、中心となるLCP、INP、CLSの3つの要素のことです。

FID（First Input Delay）は、2024年3月にGoogleによって正式にコアウェブバイタルから除外され、現在はINP（Interaction to Next Paint）に置き換えられています。今回は、そのINPのラボ環境での近似指標として使われるTBT（Total Blocking Time）を改善する方法について、現役エンジニアが解説します。

※ 2024年3月、GoogleはコアウェブバイタルのFID（First Input Delay）をINP（Interaction to Next Paint）に置き換えました。本記事は、この変更を反映してリライトしています。

INPとTBTの関係（旧FID）

FIDは、ユーザーの最初の操作に対する応答性だけを計測する指標でしたが、2024年3月にGoogleによって正式にコアウェブバイタルから除外され、現在はINP（Interaction to Next Paint）に置き換えられています。INPはFIDと異なり、ページ内で発生するすべての操作（クリック、タップ、キー入力）を対象とし、入力から画面が実際に更新されるまでの時間を計測します。良好なINPの目安は200ミリ秒以内、200〜500ミリ秒は改善が必要、500ミリ秒を超えると不良と判定されます。

INPでは、ユーザーがページ内で行ったクリックやタップなどのアクションが、実際にブラウザで処理され画面に反映されるまでの時間を計測します。

INPを計測するには、Search Console「ウェブに関する主な指標」、PageSpeed Insightsなどのフィールドデータが用いられます。Chromeの拡張機能「Lighthouse（ライトハウス）」では、INP自体をラボ環境で正確に再現することはできませんが、その近似指標としてTBT（Total Blocking Time）の計測が可能です。

TBTは合計ブロッキング時間のことで、長時間に渡りメインスレッドがブロックされ、入力の応答性が妨げられることで発生する First Contentful Paint (視覚コンテンツの初期表示時間、FCP) と Time to Interactive (操作可能になるまでの時間、TTI) の間の時間の合計を測定します。

 

 

TBTはINPとは測定対象が異なりますが、LighthouseのPerformanceスコアを構成する主要な指標の1つです。

2026年6月時点では、Performanceスコアの30%を占めています。TBTを改善することで、Lighthouseのスコア向上だけでなく、ページの応答性やユーザー体験の改善につながる可能性があり、結果としてINPの改善も期待できます。さらに、快適なユーザー体験を提供するWebサイトは、テクニカルSEOの品質向上にもつながるため、Google検索やAI Overviewなどの検索体験を見据えたサイト改善の基盤としても重要です。

コアウェブバイタルについては、「コアウェブバイタルとは？FID、LCP、CLSの改善方法もあわせて解説」で詳しく説明しています。

 

TBTはどうやって計測する？

Webサイトの改善には、TBTの見直しが必要なことはおわかりいただけたでしょうか？まずは、実際にどのようにTBTが計算されるのか、ご紹介します。

TBTを計測する方法

TBTを発見するにはいくつかツールがあります。例として Chrome developer Tool の lighthouse, Pagespeed insight, gmetrix.com ,GTmetrixなどが挙げられます。

TBTの計算方法

First Contentful Paint (視覚コンテンツの初期表示時間、FCP) と Time to Interactive (操作可能になるまでの時間、TTI)の間には、実際のサイトでは複数のタスクが発生する可能性があります。

各タスクの50ミリ秒は非TBTとみなされます。TBTはタスクごとに50msを超えた時間の合計として計算されます。

例:

TBT = (Task1実行時間 – 50ms) +  (Task2実行時間 – 50ms) + (Task3実行時間 – 50ms)

Task実行時間が 50 ミリ秒未満の場合は 50m秒 とみなされます。

上の図の場合、タスク1～2は実行時間が50msとなるため、タスク3～5で超過している分からそれぞれ50ms引いたものを合計します。

TBT=0ms(Task1)+0ms(Task2)+(Task3の実行時間-50ms)+(Task4の実行時間-50ms)+(Task5の実行時間-50ms)

TBTが低下する原因

TBTが長くなる基本的な原因は以下です。

• viewportのデフォルトの画面サイズの設定がない場合
• メインスレッドで実行される多くのサードパーティコード
• • メインスレッドで実行時間の長いJavaScriptやstyleの処理
• サーバーへのリクエストが多すぎて転送サイズが大きくなる

例：GTmetrixへ受験のミカタの記事ページ

 

TBTの具体的な改善方法

Webサイトのコアウェブバイタルを改善するには、指標として扱いやすいTBTを改善していくことが大切です。ここで紹介する施策は、TBTの数値改善だけでなく、現在のコアウェブバイタルであるINPの改善にも直結します。

viewportのメタタグに画面サイズの設定方法

viewportメタタグが設定されていない場合、ブラウザは適切な画面サイズで表示するために余分なレイアウト処理を行う必要があり、余計なリソースや時間を消費する可能性があります。そのため、以下のようにviewportメタタグを設定しておきましょう。

<meta name=”viewport” content=”width=device-width, initial-scale=1.0″>

サードパーティスクリプトの調整

以下は、サードパーティスクリプトの最もよく使用される例です。

• ソーシャル共有ボタン (Twitter、Facebook)
• ビデオ プレーヤーの埋め込み (YouTube、Vimeo)
• 広告 iframe
• 分析および指標スクリプト
• 実験用の A/B テスト スクリプト
• ヘルパー ライブラリ (日付の書式設定、アニメーション、関数ライブラリなど

サードパーティスクリプトは最適化が難しいです。 例えば、診断ツールを使用して、最も影響力のあるスクリプトを見つけるのがおすすめです。現在使用されていないスクリプト、または Web サイトに何の価値も追加しないサードパーティ サービスのスクリプトを見つけて削除します。 重要なサードパーティのスクリプトについては、次のことを検討してください。

• ドキュメントの解析がブロックされないように、async または defer 属性を使用してスクリプトをロードします。
• サードパーティのサーバーが遅い場合は、スクリプトを自己ホストすることを検討してください。
• サードパーティのスクリプトをホストしているドメインの DNS ルックアップを実行するには、<link rel=preconnect> や <link rel=dns-prefetch> などのリソースヒントを考慮してください。

これらの対応により、メインスレッドの占有時間を減らし、TBTおよびINPの短縮につながります。

メインスレッドでJavaScriptやstyleの実行時間を短縮

JavaScriptやstyleの実行時間を短縮させるためには、様々な方法が考えられます。ここではいくつかの方法を紹介します。

1. レガシーJavaScriptではなく、最新のJavaScript（ES6, ES8 など）を使用しましょう。最新のJavaScript は高速で、使用するリソースも少なくなります。
   例:

   //ES6 let calculateArea = function(height = 100, width = 50) {    // logic } //ES5 var calculateArea = function(height, width) {    height = height || 50;    width = width || 80;    // logic }

2. また、可能な限りバニラjs（プレーンJS）を使用するのがおすすめです。

   例 :

   jquery の

   $jq(‘#test-table’);

   ではなくプレーンJSで以下を使用する。

   document.getElementById(‘test-table’);

3. ページのレンダリングには使用されない JavaScript を後でロードします。
4. ページにあるフォームに係するJSをsubmit ボタン押した時にロードする。
5. ページ別に関係あるjsを分けて関係あるページにロードする。
6. クリティカルな JS とstyleが 少ない場合HTMLに埋め込む。少し大きい場合は、最小化してpreloadする。
7. Web Workerを活用する（必要に応じて）
   CPU負荷の高いJavaScript処理がある場合は、Web Workerを利用して別スレッドで実行することで、ページの応答性を改善できる場合があります。

これらの手法を組み合わせることで、メインスレッドの占有時間を大幅に削減し、TBT・INPの両方の改善につなげられます。

サーバーリクエストを最小限にする

サーバーリクエストを最小限にするために、重要ではありませんが、必要なJSやCSSを1つのファイルに結合し、最小化してロードするように設定します。

JS例：

<script defer src=”main.min.js”></script>

CSS例：

<link rel=”preload” href=”styles.min.css” as=”style” onload=”this.onload=null;this.rel=’stylesheet'”> <noscript><link rel=”stylesheet” href=”styles.min.css”></noscript>

そのほか、ファーストビューに必要な画像を除く、すべての画像を遅延ロードする設定にすることも可能です。

 

よくある質問

FIDからINPへの移行に関連して、よく寄せられる質問をまとめました。

FIDとINPは何が違いますか。

FIDはユーザーの最初の操作に対する遅延だけを計測する指標でした。一方INPは、ページ内で発生するすべての操作について、入力から画面が更新されるまでの時間を計測するため、より実際のユーザー体験に近い指標とされています。

TBTを改善すれば、INPも改善しますか。

TBTの改善はINPの改善につながる可能性が高いですが、TBTはあくまでラボ環境での近似指標であり、実際のユーザー操作に基づくINPの数値とは完全には一致しません。最終的な評価は、PageSpeed InsightsやSearch Consoleのフィールドデータで確認することをおすすめします。

TBTの改善は、どのくらいの工数で実施できますか。

viewportタグの設定など軽微な修正であれば短時間で対応できますが、サードパーティスクリプトの見直しやJavaScriptの実行時間短縮は、サイトの構成によって工数が大きく変動します。まずは診断ツールで影響度の大きい要素を特定し、優先順位をつけて対応するのがおすすめです。

 

TBT改善方法まとめ

TBTを改善する具体的な方法について紹介しました。

今回紹介したように、

• viewportメタの設定方法
• サードパーティスクリプトの調整
• • メインスレッドでJavaScriptやstyleの実行時間を短縮する方法
• サーバーリクエストを最小限にする

などの方法でTBTを改善し、コアウェブバイタルの改善にお役立てください。

 

パンタグラフではテクニカルSEOをはじめ、サーバーやサイトの内部構造の改善もサポートしています。現行のサイト運営にお困りの方は、まずは一度ご相談（無料）ください。

お問い合わせはこちら

Webサイトの応答性や使いやすさそのものを根本から見直したい場合は、UX/UIの観点からの改善も効果的です。パンタグラフのUX/UIコンサルティングでは、パフォーマンス改善とユーザー体験の両面からWebサイトの課題を整理し、改善をサポートします。