「ページは表示されているのに、ボタンをクリックしても反応が遅い」
「リンクをタップしても、画面が切り替わるまで数秒待たされる」
操作できるまでに時間がかかる状態を定量的に捉える指標が、TTI（Time To Interactive）です。TTIは、ユーザーがストレスなく操作を開始できる状態になるまでの時間を測る指標として、長年Webパフォーマンス改善の中心に位置づけられてきました。
現在はLighthouseのアップデートにより主要指標から外れましたが、「いつページが本当に使えるようになるのか」というTTIの視点は、今でもWebサイト改善に欠かせません。
本記事では、TTIの基本的な定義や重要視されてきた理由、INPといった関連指標との関係に触れつつ、LighthouseやPageSpeed Insightsを用いた測定方法などを最新情報を踏まえて解説します。
TTIの考え方を押さえて、ユーザーにも検索エンジンにも評価される、応答性の高いWebサイトづくりに役立てていきましょう。
TTI（Time To Interactive）とは？
WebパフォーマンスにおけるTTI（Time To Interactive）とは、インタラクティブになるまでの時間を意味する指標です。これは、Webページが表示されてから、ユーザーがストレスなく操作（クリックや入力など）できるようになるまでの時間を示します。
単にコンテンツが見えるだけでなく、ユーザーのアクションに素早く応答できる状態になることが重要です。
TTIの定義
TTIは、以下の3つの条件がすべて満たされた時点として定義されていました。
- FCP（First Contentful Paint）を過ぎていること
- ページのコンテンツ（テキストや画像など）が初めて画面に表示される
- 主要な要素のイベントハンドラが登録されていること
- ページの大部分のUI要素が操作可能になっている
- ユーザーの操作に対して一貫して50ミリ秒以内に応答できること
- メインスレッドが少なくとも5秒間アイドル状態（長いタスクが発生していない静かな状態）になっているこ
つまり、見た目が完成し、かつシステム的にもユーザー操作を受け付ける準備が整った状態がTTIです。
TTIが重要視されてきた理由
TTIが重要視されてきた背景には、ユーザー体験（UX）への直接的な影響があります。ボタンを押しても反応がない、リンクをクリックしてもページが遷移しないといった状態は、ユーザーに大きなストレスを与えます。
その結果、ユーザーはWebサイトから離脱してしまい、商品購入や問い合わせといったビジネス機会の損失につながっていくからです。
Googleもユーザー体験を重視しているため、TTIのような表示速度に関する指標は、SEO（検索エンジン最適化）においても重要な要素と考えています。
現在におけるTTIの位置づけと測定状況
技術の進化に伴い、Webパフォーマンスを評価する指標も変化しています。2023年2月のLighthouse 10のアップデートにより、TTIは主要な評価指標から削除されました。
現在では、ユーザーの操作に対する応答性をより正確に測るため、INP（Interaction to Next Paint）という新しい指標が重視されています。
INPは、実際のユーザー操作（クリック・タップ・キーボード入力など）に対して、画面が次の表示を行うまでにどれだけ時間がかかったかを評価する指標で、「操作したのに反応が返ってこない時間」をダイレクトに数値化します。
あわせて、ラボ環境でのボトルネック把握に役立つのが、TBT（Total Blocking Time）です。
TBTは、ページの読み込み中にメインスレッドが50ミリ秒を超えてブロックされている時間の合計を示す指標で、長いJavaScript処理や重いタスクが「どれだけユーザー操作を妨げているか」を把握するのに適しています。
このように、TTI自体は主要指標から外れましたが、「いつページが本当に使えるようになるのか」を捉える考え方は、現在のWebサイト全体のパフォーマンス向上にも直結します。TTIの背景にある思想を理解しておくことは、今でも十分に価値が高いといえます。
TTIの目安値と評価基準
TTIが指標として使われていた当時、Googleは明確な評価基準を設けていました。ここでは、過去の基準を参考に、パフォーマンスの目安について解説します。
Google公式のTTI評価基準（参考情報）
PageSpeed Insightsなどでは、TTIの測定結果が以下の3段階で評価されていました。この数値は、現在でもWebサイトの応答性を考える上での一つの目安となります。
| 評価 | TTIの秒数 | 状態 |
| 速い （Good） | 0～3.8秒 | ユーザーはストレスなく操作を開始できる |
| 平均 （Needs Improvement） | 3.9～7.3秒 | ユーザーは操作可能になるまで少し待たされる感覚を持つ可能性がある |
| 遅い （Poor） | 7.3秒以上 | ユーザーは明らかな遅延を感じ、ストレスや離脱の原因となる |
自社サイトの現状を正しく評価する方法
現在、TTIは直接測定できませんが、Webサイトの応答性を評価することは依然として重要です。
LighthouseやPageSpeed Insightsを使用し、インタラクティブ性を評価する後継指標であるINPや、メインスレッドをブロックする要因となるTBT（Total Blocking Time）を確認しましょう。
これらの指標を改善することが、結果的に過去のTTIが目指していた快適なユーザー体験につながります。
実務に活かす際は、あらかじめ目標ラインを決めておくことが大事です。例えば、INPであれば、Core Web Vitalsで定義されている「良好（Good）」の水準をベースラインとし、特に重要なページ群から優先的に、この水準に乗せていく方針を取るのが現実的です。
全ページを一気に改善しようとするのではなく、まずは主要10〜20ページでINPを安定して良好にするといった単位で区切ると、チーム内でも合意しやすくなります。
TBTについても同様に、まずは代表的なページでどのくらいメインスレッドがブロックされているのかを把握し、長いタスクや重いJavaScriptが多いページから順に改善しましょう。
TBTはラボ環境の指標なので、完璧な数字を追いかけるよりも、主要ページのTBTを一定水準以下に抑えられているかを確認すると運用しやすいです。
INPとTBTを合わせて見ることで、「ユーザーの手元でどれだけ待たされているのか」と「その原因がどこにあるのか」の両方を押さえながら改善を進められます。
このように、INPやTBTを使ってWebサイトの現状を定期的に測り、ページの重要度に応じた現実的な目標ラインを設定・改善していくことが重要です。
TTIの測定方法
ここでは、過去に行われていたTTIの主な測定方法を解説します。紹介するツールは現在も利用可能で、TTI以外の重要なパフォーマンス指標を測定するために不可欠です。
PageSpeed InsightsでTTIを確認する
PageSpeed Insightsは、URLを入力するだけで対象ページのパフォーマンスを分析できるGoogle公式のツールです。診断したいページのURLを入力して「分析」ボタンを押すと、数十秒ほどで結果が表示され、上部にスコア、下部に詳細な指標や改善提案が並びます。
以前はこのレポートの中にTTIの項目がありましたが、現在は表示されません。代わりに、「合計ブロック時間（TBT：Total Blocking Time）」や「Interaction to Next Paint（INP）」といった指標を確認でき、応答性に関する問題を把握する際に役立てられます。
まずPageSpeed Insightsにアクセスし、計測したいページのURLを入力して結果を確認してみてください。表示されたレポートを下にスクロールすると「フィールドデータ」「ラボデータ」などのセクションがあり、その中にTBTやINPが含まれています。
これらの数値を目安にしながら、「どこで処理が重くなっているのか」「ユーザーがどの程度待たされていそうか」を把握し、改善のヒントを得ましょう。
Lighthouse（Chrome DevTools）で測定する
Google Chromeのデベロッパーツールに内蔵されているLighthouseでも、詳細なパフォーマンス分析が可能です。こちらも現在はTTIのスコアは表示されませんが、パフォーマンスレポート内の「改善できる項目」を確認することで、応答性を低下させている原因を特定できます。
実ユーザーデータ（RUM）で計測する
PageSpeed InsightsやLighthouseが特定の環境で測定する「ラボデータ」であるのに対し、RUM（Real User Monitoring）は実際のユーザー環境からデータを収集します。
Google Analytics 4 （GA4） やその他の専用ツールを導入することで、多様なデバイスやネットワーク環境における実際のユーザー体験を把握できます。INPなどの指標をRUMで計測し、特定ユーザー層の問題を明らかにすることが可能です。
TTIが悪化する主な原因
TTIが悪化する原因は、主にWebページの裏側で動くプログラム、特にJavaScriptに起因することが多いです。ここでは、代表的な4つの原因を解説します。
大量・重いJavaScriptの読み込み
Webサイトに複雑なアニメーションやインタラクションを実装するために、多くのJavaScriptが使われています。
しかし、これらのスクリプトの量が多い、または一つひとつの処理が重いと、ブラウザがすべての処理を終えるまでに時間がかかります。その結果、ユーザーがページを操作できる状態になるまでに時間がかかる仕組みです。
メインスレッドをブロックする「長いタスク（long task）」
ブラウザは「メインスレッド」と呼ばれる一本道で、JavaScriptの実行やユーザー操作への対応など、多くの処理を順番に行っています。一つの処理が50ミリ秒以上かかると長いタスクと見なされ、その処理が終わるまで他の作業がすべて中断される仕組みです。
長いタスクが発生すると、ユーザーがクリックしてもブラウザが反応できず、TTIが悪化する要因となります。
外部スクリプト・タグ（広告・計測・ウィジェット など）
アクセス解析ツールやWeb広告、SNSの埋め込みボタンなど、多くのWebサイトが外部サービスを利用しています。外部スクリプトは、Webサイトのパフォーマンスを低下させる一因となることがあります。
外部サーバーの応答が遅い場合や、スクリプト自体の処理が重い場合は、自社サイトの表示速度まで引きずられてしまうかもしれません。
画像・フォント・CSSなどリソースの最適化不足
Webページを構成するのはJavaScriptだけではありません。画像やWebフォント、CSSファイルなどもページの読み込み時間に影響します。
特にサイズの大きな画像が圧縮されていなかったり、不要なCSSが大量に読み込まれていたりすると、全体のダウンロード時間が長くなり、TTIの悪化につながります。
TTIを改善するための実践的な対策
TTIの考え方に基づき、Webサイトの応答性を改善するための具体的な対策を紹介します。以下の手法は、現在のINPやTBT、LCPといったCore Web Vitalsの改善にも非常に効果的です。
画像・フォントの最適化
ユーザーに表示されるコンテンツの中で、特にファイルサイズが大きくなりがちなのが画像です。
適切なサイズにリサイズし、WebPやAVIFといった次世代フォーマットで配信することで、画質を保ちながらファイルサイズを大幅に削減できます。また、画面に表示されていない画像を後から読み込む「遅延読み込み」も効果的です。
あわせて、フォントの最適化も重要なポイントです。Webフォントを多用している場合は、使っていない文字種を削ったサブセットフォントを利用したり、font-display を適切に設定して文字がしばらく表示されない時間を減らしたりすることで、体感速度を改善できます。
必要なフォントファイルを最小限に絞りつつ、場合によってはシステムフォントの活用も検討すると、画像だけでなくテキスト表示の面からもパフォーマンスを底上げすることが可能です。
JavaScriptの最適化と分割読み込み
Webサイトの動作に不要なJavaScriptコードは、パフォーマンスを低下させるだけの重りです。
コード分割（Code Splitting）を行い、今すぐ必要でないコードは後から読み込むようにしましょう。
また、コードから不要な改行や空白を削除する「圧縮（Minify）」も、ファイルサイズ削減に貢献します。
長いタスクの分割と非同期処理
メインスレッドを長時間ブロックする長いタスクは、小さな処理に分割することが重要です。一つの大きな処理を複数の小さなタスクに分けることで、合間にユーザー操作を処理する余裕が生まれます。
また、重い処理をメインスレッドとは別の場所で実行する「Web Workers」の活用も有効な手段です。
サードパーティスクリプトの最適化
利用している外部スクリプトが本当にすべて必要か、定期的に見直しましょう。不要になったタグは削除し、必要なものについても async や defer 属性を用いて非同期で読み込むことで、ページの描画を妨げないように設定できます。
画像最適化ツールを活用する
手動での画像最適化には限界があります。そこで、Imgixのような画像最適化・配信サービスを活用するのも一つの手です。AIがリアルタイムで最適なフォーマットや圧縮率を判断し、CDN経由で高速配信してくれるため、工数をかけずに高いパフォーマンスを実現できます。
さらに、元画像を一枚用意しておけば、URLパラメータを変更するだけでサイズ変更やトリミング、画質調整などを行えるのも特徴です。
デバイスや表示位置ごとに最適な画像を自動生成してくれるため、「どのサイズの画像を何種類用意するか」といった設計や運用の負担を大幅に減らせます。
TTIに関するよくある質問
ここでは、TTIや関連指標について、多くの人が抱く疑問にお答えします。
TTIはCore Web Vitalsの一部なのか
いいえ、TTIはCore Web Vitalsの指標ではありません。Core Web Vitalsは、LCP（読み込み速度）、INP（インタラクティブ性）、CLS（視覚的な安定性）の3つで構成されています。
TTIは、INPより前にインタラクティブ性を測る目的で使われてきた指標ですが、現在はその役割の多くをINPが引き継いでいます。
SEO的にTTIが悪いと順位は下がるのか
TTIという指標自体が直接的に検索順位を下げることはありません。しかし、TTIが悪いということはWebサイトの応答性が低く、ユーザー体験を損なっている可能性が高いことを意味します。
ユーザー体験の悪化は、直帰率の上昇や滞在時間の減少につながり、間接的にSEO評価へ悪影響を及ぼす可能性があります。
まずどの指標から改善すべきなのか
まずは、Googleが最重要指標と位置づけるCore Web Vitals（LCP・INP・CLS）の改善から着手することがおすすめです。
特に、インタラクティブ性を評価するINPのスコアが悪い場合は、この記事で紹介したTTIが悪化する原因と改善策がそのまま役立ちます。各指標のバランスを見ながら、総合的なパフォーマンス向上を目指しましょう。
まとめ TTIへの理解を深めて満足度の高いWebサイトを構築しよう
この記事では、Webパフォーマンス指標として使われてきたTTIについて解説しました。Webの世界において、指標としてのTTIは役目を終えましたが、その考え方は今後も重要であり続けるでしょう。
後継指標であるINPやCore Web Vitalsへの理解を深め、この記事で紹介した改善策を実践することで、ユーザーにとっても検索エンジンにとっても価値のあるWebサイトを構築できます。
