TTFBとは？サイトが表示され始めるまでの待ち時間と改善方法
Webサイトを開いたとき、しばらく画面が白いままになることはありませんか。その原因を調べる際に役立つ指標のひとつが「TTFB」です。
この記事では、TTFBの意味と目安、無料での確認方法、WordPressで見直したいポイントを解説します。
TTFBとは？
TTFBは「Time to First Byte」の略で、ページへの移動を開始してから、応答の最初の1バイトを受け取るまでの時間です。
読み方は「ティー・ティー・エフ・ビー」。日本語では「最初のバイトまでの時間」などと呼ばれます。
レストランにたとえると、注文してから最初の料理が届くまでの待ち時間に近い指標です。すべての料理が出そろう時間とは違います。
Webページも、最初の応答が届いた後にHTMLの受信や解析、画像などの読み込み、画面の描画が続きます。TTFBが短くても、それだけでページ全体が速いとは限りません。
TTFB・FCP・LCPの違い
| 指標 | 確認すること |
|---|---|
| TTFB | 最初の応答が届くまでの時間 |
| FCP | 文字や画像などのコンテンツが初めて描画されるまでの時間 |
| LCP | 表示領域内で最大の画像やテキストブロックが描画されるまでの時間 |
たとえば、最初の応答はすぐに届くのに大きな画像の表示が遅い場合、TTFBよりも画像の配信や描画を調べるほうが適切です。
反対に、応答が届くまで長く待たされる場合は、通信やサーバー側の処理を確認します。
TTFBは何秒なら良い？
Googleのweb.devでは、次の目安を示しています。
| TTFB | 評価の目安 |
|---|---|
| 0.8秒以下 | 良好 |
| 0.8秒を超え、1.8秒以下 | 改善が必要 |
| 1.8秒を超える | 不良 |
1,000ミリ秒（ms）は1秒です。800msなら0.8秒になります。
この基準は大まかな目安です。実ユーザーの評価では75パーセンタイル、つまり利用者の75％がその時間以内に収まる値を確認します。自分のパソコンで一度だけ測った数値とは区別しましょう。
なお、**TTFB自体はCore Web Vitalsの指標ではありません。**ただし、応答が遅れるとコンテンツの表示開始も遅れやすいため、表示速度を調べる入口になります。
TTFBが遅くなる原因
通信や接続に時間がかかる
TTFBには、サーバーの処理だけでなく、DNSによる接続先の確認、接続の確立、HTTPSの通信準備なども含まれます。訪問者とサーバーの距離や通信環境によっても数値は変わります。
ページを作る処理が重い
WordPressは、リクエストを受けるとPHPやデータベースを使ってページを生成します。重いデータベース処理、外部サービスの応答待ち、サーバーのリソース不足などがあると、最初の応答が遅れることがあります。
キャッシュを利用できていない
ページキャッシュは、生成済みのページを再利用する仕組みです。毎回ページを作り直す必要が減り、サーバーの負担を軽くできます。
ただし、キャッシュの有無で結果が大きく変わる場合があります。よく読まれる記事だけでなく、アクセスの少ない記事も測ると実態を把握しやすくなります。
リダイレクトが何段階もある
「旧URL→別のURL→最終URL」のような転送の連鎖は、追加の待ち時間を生みます。内部リンクは、できるだけ最終的な正規URLへ直接つなげましょう。
TTFBを無料で確認する方法
PageSpeed Insightsで確認する
PageSpeed InsightsにURLを入力し、実ユーザーのデータがある場合はTTFBを確認できます。
実ユーザーのデータは、直近28日間のChrome UX Report（CrUX）に基づきます。ページ単位のデータが不足するとサイト全体のデータが使われることがあり、それも不足すると表示されません。
**「データなし」は、TTFBが悪いという意味ではありません。**公開直後のページや、対象となる実ユーザーのサンプルが少ないページでは、数値を表示できないことがあります。
また、実ユーザーのデータと、下部のテスト環境での診断結果は別です。設定変更の効果を確認するときは、この違いを意識しましょう。
出典：Google：PageSpeed Insightsについて
Chromeの開発者ツールで確認する
- Chromeで対象ページを開く。
- 開発者ツールを開き、「Network」を選ぶ。
- ページを再読み込みする。
- 種類が「document」のメインページを選ぶ。
- 「Timing」で通信の内訳を確認する。
「Waiting for server response」は応答待ちの区間です。ページ移動開始からのTTFBを考える際は、DNSや接続などの区間も確認します。
自分の回線やブラウザのキャッシュ状態に影響されるため、一度の結果だけで判断しないことが大切です。
WebPageTestで確認する
WebPageTestも、TTFBや通信の内訳を調べる選択肢です。無料利用の範囲や選択できる条件は、利用時に確認してください。
測定場所や端末などの条件をそろえると、改善前後を比較しやすくなります。
WordPressでTTFBを改善するには？
まずは、次の順番で確認すると原因を絞りやすくなります。
- 一般読者と同じ条件で測る
管理者からログアウトし、トップページと複数の記事を同じ条件で測定します。 - ページキャッシュの動作を確認する
キャッシュ機能を有効にしただけでなく、公開ページで実際に使われているか確認します。 - 処理の重い部分を調べる
プラグイン、テーマ、データベース処理、外部APIなどを確認します。プラグインは数だけで判断せず、処理内容を見ます。 - サーバー環境を確認する
CPUやメモリの不足、負荷の集中、対応するPHP環境などを確認します。変更する場合は互換性も確認しましょう。 - 必要に応じてCDNやオブジェクトキャッシュを検討する
CDNは訪問者に近い場所から配信する仕組みです。オブジェクトキャッシュはデータベース処理の結果などを再利用します。
WordPressの公式資料でも、ページキャッシュ、永続オブジェクトキャッシュ、CDNなどが改善策として紹介されています。
ただし、画像やCSSだけをCDNで配信していても、メインHTMLの生成待ちは残ることがあります。HTMLのキャッシュ対象や配信経路も確認してください。
ログイン後の個人情報ページや購入手続きなどは、公開記事と同じキャッシュ設定にしないよう注意が必要です。
よくある質問
画像を軽くすればTTFBは改善しますか？
画像の軽量化は、転送量やLCPの改善に役立ちます。ただし、メインHTMLの最初の応答を待つ時間とは別の問題です。TTFBが遅い場合は、まず通信やページ生成処理を確認しましょう。
TTFBが短ければサイトは速いですか？
それだけでは判断できません。応答が早くても、画像やJavaScriptの処理が重ければ表示は遅くなります。FCPやLCPと合わせて確認してください。
TTFBが遅いと検索順位が下がりますか？
TTFBの数値だけで検索順位が決まるとはいえません。まずは、読者がコンテンツを快適に表示できるかを考え、ページ全体の表示速度と使いやすさを改善しましょう。
まとめ
TTFBは、ページへの移動を開始してから、最初の応答が届くまでの待ち時間です。目安は0.8秒以下ですが、測定条件やキャッシュの状態によって数値は変わります。
WordPressでは、一般読者の条件で複数のページを測り、キャッシュ、ページ生成処理、サーバー環境を順に確認しましょう。TTFBと実際の表示速度を合わせて見ることで、改善すべき場所が見つけやすくなります。
関連記事：コアウェブバイタル
