TTFBとは？800msと600msは何が違うのか、直す前に見ること

TTFBとは、サーバーが最初の1バイトを返すまでの時間

TTFBは Time to First Byte の略で、ブラウザがリクエストを送ってから、サーバーの応答の最初の1バイトが届くまでの時間です。ページが表示し終わるまでの時間ではありません。

この時間には、ドメイン名からIPアドレスを引くDNS参照、リダイレクトの処理、サーバーがHTMLを組み立てる時間が含まれます。画像やCSSの読み込みは、この後に始まります。

表示速度そのものではなく、その前段にある時間

TTFBが遅いと、その後の処理がすべて後ろにずれます。だからこそ気にされやすい指標です。

ただし、TTFBが速くても表示が遅いサイトはあります。HTMLの返却は速いのに、その後で大量のJavaScriptを読み込んでいれば、利用者が見る画面は遅いままです。TTFBは表示速度の一部であって、全体ではありません。

Core Web Vitalsの指標には含まれていない

Googleが検索の評価に使うCore Web Vitalsは、LCP・INP・CLSの3つです。TTFBはこの中に入っていません。

web.devには、TTFBはCore Web Vitalsの指標ではないため、後続の指標のスコアを妨げていない限り、良好の閾値を満たすことは絶対に必要ではないと明記されています。数値が基準を外れていても、TTFBそのものが順位を下げるわけではありません。

• 参考：Time to First Byte (TTFB)
• 関連記事：Core Web Vitalsとは？3指標の意味と、直さなくていい場合の見分け方

TTFBの800msと600msは、測っている範囲が違う

2つの数値が流通しているのは、基準が2種類あるからではありません。同じ処理を、違う範囲で切り取っているだけです。

800msはDNSとリダイレクトを含む全体

web.devが示す0.8秒以下という目安は、TTFB全体に対するものです。DNS参照、リダイレクト、サーバーの応答をすべて足した時間を指します。

1.8秒を超えると「改善が必要」の区分に入ります。ただし前述のとおり、これは絶対に守るべき数値ではありません。

600msはサーバーの応答だけ

PageSpeed Insightsやデベロッパーツールが600msを超えると警告するのは、サーバーの応答時間に対してです。DNS参照とリダイレクトの時間は含まれていません。

Chrome公式のドキュメントにも、TTFBの推奨値である800msがサーバー応答時間の推奨値600msより長いのは、TTFBがDNS参照とリダイレクトの処理を含むためだと書かれています。

どちらを超えているかで原因が分かる

この関係が分かると、2つの数値は競合ではなく手がかりになります。

状態	疑う場所
600msを超えている	サーバー側の処理。テーマ、プラグイン、データベース
600msは収まり800msを超える	DNS参照かリダイレクト
両方とも収まっている	TTFBは問題ない

600msに収まっているのに800msを超えるなら、サーバーではなく手前で時間を使っています。リダイレクトが何段も挟まっていないかを先に見ます。

両方を超えている場合は、サーバー側から手を付けます。DNSとリダイレクトの時間はもともと短いため、そちらを削っても全体は大きく変わりません。まずサーバー側で600msを切ることを目標にし、そのうえで800msに収まらなければ、DNSとリダイレクトを見直します。

• 参考：Document request latency
• 参考：Optimize Time to First Byte

TTFBを直す前に見る3つのこと

TTFBの警告が出ていても、直す必要がないことがあります。先に確認する順序を決めておくと、不要な作業を避けられます。

LCPは基準内に収まっているか

最初に見るのはLCPです。ページの主要な部分が表示されるまでの時間で、2.5秒以内なら良好とされます。TTFBはこのLCPを構成する4区間のうち、1つ目にあたります。

LCPが基準内なら、TTFBが800msを超えていても直す優先度は低くなります。TTFBを縮める目的は後続の指標を改善することなので、その後続が満たせているなら目的は達成されています。

実測値か、参考値か

PageSpeed Insightsは2種類のデータを出します。実際の利用者から集めた実測値と、その場で1回測った参考値です。

判断に使うのは実測値です。参考値は測定環境の影響を受けやすく、サーバー側のキャッシュが効いた瞬間を測れば実態より速く出ます。逆に、初回アクセスを測れば遅く出ます。

実測値は画面の上のほうに「実際のユーザーの環境で評価する」という見出しで表示されます。ここにTTFBの項目がなければ、まだ集計に必要な件数が集まっていません。その場合はドメイン全体のデータに切り替えると、表示されることがあります。

実測値は画面の上のほうに「実際のユーザーの環境で評価する」という見出しで表示されます。ここにTTFBの項目がなければ、まだ集計に必要な件数が集まっていません。その場合はドメイン全体のデータに切り替えると、表示されることがあります。

遅いのは全ページか、特定のページだけか

トップページだけが遅いのか、記事ページも同じように遅いのかで、原因の範囲が変わります。

特定のページだけ遅いなら、そのページ固有の処理を疑います。全ページが均等に遅いなら、テーマかサーバーの側です。1ページだけで決めず、3ページ以上を比べてから判断します。

• 関連記事：LCPとは？画像を圧縮しても直らない理由と、4つの区間の見つけ方

TTFBの原因を切り分ける手順

改善策を並べる前に、どこで時間を使っているかを特定します。順番を守ると、無駄な設定変更をせずに済みます。

リダイレクトが挟まっていないか

最初に見るのはリダイレクトです。1回のリダイレクトで、ネットワークの往復が1回増えます。

よくあるのは、httpからhttpsへの転送と、末尾のスラッシュの有無による転送が重なっている状態です。2段になっていれば、その分だけTTFBに直接上乗せされます。

何段あるかは、開発者ツールで確認できます。F12で開発者ツールを開き、ネットワークのタブを選びます。「ログを保存」にチェックを入れてからページを読み込むと、転送された分も履歴に残ります。一覧の一番上から順に、状態が301や302になっている行を数えます。

2段以上あるなら、最終的なURLへ直接向かうよう設定を見直します。あわせて、サイト内のリンクも最終的なURLに直します。転送を減らすのではなく、そもそも転送させないのが目的です。

静的HTMLファイルと比較する

サーバー自体が遅いのか、WordPressの処理が遅いのかを分けます。

手順は単純です。テキストエディタで「test」とだけ書いたファイルを作り、拡張子を .html にして保存します。サーバーのファイルマネージャで、サイトの一番上の階層にアップロードします。

そのファイルのURLを開き、開発者ツールのネットワークのタブで応答時間を見ます。数十ミリ秒で返るのが正常です。静的ファイルが速いのにWordPressのページが遅いなら、原因はサーバーではなくサイト側です。

逆に、この1行のファイルすら遅いなら、サーバーの性能かネットワークの問題です。テーマやプラグインをいくら見ても改善しません。確認が終わったらファイルは削除してください。置いたままでも実害はありませんが、不要なファイルは残さないほうが管理しやすくなります。

テーマとプラグインを切り分ける

サイト側に原因があると分かったら、テーマを一時的に既定のものへ切り替えて測ります。それで速くなればテーマ、変わらなければプラグインです。

プラグインは全部を停止してから1つずつ戻します。1つ戻すたびに測ると、どれが重いかが分かります。本番サイトで行う場合は、アクセスの少ない時間帯を選びます。

この作業の前に、必ずバックアップを取ってください。停止したプラグインを戻したときに、設定が失われることがあります。とくにフォームや会員機能に関わるものは慎重に扱います。

1つずつ戻すのは手間がかかるため、半分ずつ戻す方法もあります。10個あれば5個ずつに分け、遅いほうをさらに半分に分ける。この方法なら4回ほどで絞り込めます。

レンタルサーバーでTTFBに対してできること

共用のレンタルサーバーでも、管理画面から変えられる範囲があります。移転を考える前に、契約を変えずに直せることを先に試します。

圧縮とキャッシュを有効にする

テキスト圧縮が無効だと、HTMLがそのままの大きさで送られます。設定ファイルを書き換える必要はなく、管理画面のスイッチ1つで有効にできます。

サーバー側のキャッシュも同様です。ただしキャッシュは、遅い処理を隠してしまう面もあります。原因を調べるときは、一時的に切って測ります。

PHPのバージョンを上げる

古いバージョンのままだと、同じ処理でも時間がかかります。管理画面から切り替えられますが、テーマやプラグインが対応していないと表示が崩れます。

切り替える前に、バックアップを取ってから作業してください。当サイトはプラグインを使っていないため、この種の非互換が起きる箇所がテーマだけに限られます。

プラン変更や移転を検討する基準

上の3つを試しても静的ファイルの応答が遅いままなら、サーバーの性能そのものが足りていません。共用サーバーでは、同居している他のサイトの負荷を自分では動かせないためです。

ただし移転は、ドメインの設定変更とデータの移動を伴います。先に切り分けを終えて、原因がサーバーだと確定してから判断します。

判断の目安は、先ほどの1行のHTMLファイルです。これが200ミリ秒を超えて返るなら、サーバー側に余裕がありません。共用プランの上位に変えるか、別の会社に移すかの検討に入ります。

移転先を選ぶときは、表示速度の宣伝文句ではなく、1台のサーバーに何サイトを収容しているかを見ます。公表していない会社が大半ですが、無料お試し期間があれば、同じ1行のファイルを置いて測れば分かります。

• 関連記事：WordPressで作るメリット｜プラグインを入れないという選択肢

まとめ

TTFBの2つの数値は、対立する基準ではありません。800msが全体で、600msはそのうちのサーバー応答の部分です。どちらを超えているかで、疑う場所が変わります。

そしてTTFBはCore Web Vitalsの指標ではないため、LCPが基準内に収まっていれば手を付ける優先度は下がります。警告が出たからという理由だけでサーバーを移す必要はありません。

まずPageSpeed Insightsを開き、実測値のTTFBとLCPを並べて見るところから始まります。LCPが2.5秒以内なら、その日は記事を書く時間に回してください。

速度を直しても順位が動かない場合は、原因が別の層にあります。検索順位が上がらない原因で、上から順に確認する手順をまとめています。