TTFBとは？改善・短縮の前に見る3つのことと、800msと600msの違い

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

TTFBは「Time to First Byte」の略です。ブラウザがページを求めてから、サーバーの応答の最初の1バイトが届くまでの時間を指します。

ページが表示し終わるまでの時間ではありません。画像やCSSの読み込みは、このあとに始まります。名前から受ける印象より、測っている範囲はずっと狭いのです。まずは、この時間が何を含むかを押さえてください。

TTFBに含まれる時間

TTFBには、ページを受け取る前のいくつかの段階が含まれます。主なものは次の4つです。

• ドメイン名から住所を引く時間
• サーバーとつながる時間
• リダイレクトの処理
• サーバーがHTMLを組み立てる時間

どこで時間を使っているかで、直す場所が変わります。数値が遅いときは、この4つのどこが長いかを見分けることから始めてください。

TTFBは、Core Web Vitalsに含まれない

Googleが重視するCore Web Vitalsは、LCP、INP、CLSの3つです。TTFBは、この中に入っていません。

web.devの説明では、TTFBはCore Web Vitalsではありません。大事な指標を妨げていない限り、良好の基準を満たすことは絶対に必要ではないとされています。数値が基準を外れていても、それだけで直す理由にはなりません。

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

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

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

この関係が分かると、2つの数値は食い違いではなく、原因を探す手がかりになります。どちらを超えているかで、疑う場所は次のように変わります。

状態	疑う場所
サーバーの応答が600msを超える	サーバー側の処理、テーマ、プラグイン
600msには収まり、全体が800msを超える	ドメイン名の参照、リダイレクト
両方とも収まっている	TTFBは問題ない

800msは、全体の目安

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

1.8秒を超えると、遅いという区分に入ります。ただし、web.dev自身がおおまかな目安だと断っており、絶対に守るべき数値ではありません。数値は、サイトの作りや利用者の地域でも変わります。

600msは、サーバーの応答だけの目安

Chromeの開発者ツールは、サーバーの応答に600msを超えて時間がかかると知らせます。こちらには、ドメイン名の参照とリダイレクトの時間は含まれていません。

Chromeの公式の説明にも、800msが長いのは参照と転送を含むためだとあります。両方を超えているなら、サーバー側から先に手を付けてください。

• 参考：Document request latency

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

TTFBの警告が出ていても、直す必要がないことがあります。先に確かめる順番を決めておくと、要らない作業を避けられます。警告の色だけを見て、慌てて作業を始めないでください。

次の3つを、上から順に見てください。1つ目で問題がなければ、TTFBに手を付ける優先度はぐっと下がります。3つを確かめるのに、長い時間はかかりません。

① LCPは基準内か

最初に見るのは、LCPです。ページの主な部分が表示されるまでの時間で、2.5秒以内なら良好とされます。

TTFBは、このLCPを形づくる4つの区間の1つ目です。LCPが基準内なら、TTFBを縮める目的はすでに果たされています。この場合、その日は直さなくて構いません。LCPが遅いときだけ、TTFBの区間が長いかを確かめます。

② 実測値か、参考値か

PageSpeed Insightsが出す数値は、実測値と参考値の2種類です。判断に使うのは、実測値です。

参考値は、測った瞬間の状態に左右されます。サーバーのキャッシュが効いた瞬間なら速く、最初のアクセスなら遅く出ます。実測値の欄にTTFBがなければ、集計に足りる件数がまだ集まっていません。その場合は、ドメイン全体の数値に切り替えて見てください。

③ 全ページか、一部のページか

トップページだけが遅いのか、記事のページも同じように遅いのかで、原因の範囲が変わります。比べるページは、種類の違うものを選ぶのがこつです。

特定のページだけが遅いなら、そのページ特有の処理を疑います。全ページが同じように遅いなら、テーマかサーバーの側です。3ページ以上を比べてから判断してください。原因の範囲が分かれば、試す作業の数を減らせます。

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

TTFBを短縮するために原因を切り分ける3つの手順

直す方法を並べる前に、どこで時間を使っているかを突き止めます。順番を守れば、要らない設定変更をせずに済みます。思いついた方法を手当たりしだいに試すと、効いたものが分からなくなるのが落とし穴です。

3つの手順は、手前から奥へ進む形です。1つ確かめるたびに数値を記録しておくと、どこで改善したかが分かります。途中で原因が見つかれば、その先の手順は要りません。

① リダイレクトの段数を見る

最初に見るのはリダイレクトです。1回のリダイレクトで、やり取りが1往復増えます。

よくあるのは、httpsへの転送と、末尾のスラッシュの転送が重なる状態です。開発者ツールのネットワークの欄で、301や302の行を数えてください。2段以上あるなら、最終的なURLへ直接向かうよう設定と内部リンクを直します。

② 1行のHTMLファイルと比べる

サーバーそのものが遅いのか、WordPressの処理が遅いのかを分けます。「test」とだけ書いたHTMLファイルを作り、サイトの一番上の階層に置いて応答時間を測ります。

この1行のファイルが速く返るのにWordPressのページが遅いなら、原因はサイトの側です。逆に、1行のファイルすら遅いなら、サーバーの性能かネットワークの問題です。確かめ終えたら、ファイルは消しておいてください。

③ テーマとプラグインを切り替える

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

プラグインは、全部を止めてから半分ずつ戻すと早く絞り込めます。10個あれば5個ずつに分け、遅いほうをさらに半分に分ける形です。作業の前には、必ず控えを取ってください。

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

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

移転は、ドメインの設定変更とデータの移動を伴う大きな作業です。原因がサーバーだと確定してから判断します。移す前に、管理画面でできることを済ませてください。

圧縮とキャッシュ

文字の圧縮が無効だと、HTMLがそのままの大きさで送られます。多くのサーバーでは、管理画面のスイッチ1つで有効にできます。

サーバー側のキャッシュも同じです。ただし、キャッシュは遅い処理を隠してしまう面もあります。原因を調べるときは、一時的に切って測るのが、本当の速さを知るこつです。有効にしたら、同じページで前と後の数値を比べます。

PHPのバージョン

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

切り替える前に、必ず控えを取ってください。当サイトはプラグインを使っていないため、こうした食い違いが起きる場所がテーマだけに限られます。プラグインが多いほど、切り替えの前の確認に手間がかかります。

移転を考える基準

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

移転先を選ぶときは、宣伝文句ではなく、試用の期間に同じ1行のファイルを置いて測るのが確実です。測った数値を、今のサーバーと並べて比べてください。

• 参考：Optimize Time to First Byte
• 関連記事：サイトの表示速度を改善する｜プラグインを入れる前に見る3か所

TTFBに関するよくある質問

TTFBが遅いと、検索順位は下がりますか

TTFBそのものは、Core Web Vitalsの指標ではありません。web.devも、良好の基準を満たすことは絶対に必要ではないとしています。

ただし、TTFBが極端に遅いと、そのあとのLCPも遅れるのが難点です。LCPが基準を外れているなら、TTFBを縮めることに意味が出てきます。判断は、TTFB単体ではなくLCPと並べて行ってください。

PageSpeed Insightsで毎回数値が変わります

参考値は、測るたびに変わるのが普通です。サーバーの混み具合やキャッシュの状態で、結果が上下します。

判断には、実際の利用者から集めた実測値を使ってください。参考値で比べるなら、同じ時間帯に何回か測って、真ん中くらいの値を見るのが確実です。1回の結果で設定を変えると、効果があったのかが分からなくなります。実測値は日々少しずつ入れ替わるため、変化はゆっくり表れます。

キャッシュのプラグインを入れれば解決しますか

速くなることは多いものの、原因が残ったまま隠れるだけのこともあります。まずは、どこで時間を使っているかを切り分けてください。

サーバーの管理画面にキャッシュの機能があるなら、プラグインを足す前にそちらを試します。両方でキャッシュを効かせると、更新が反映されない不具合が起きることもあります。入れる場合は、入れる前と後の数値を比べてください。

海外のサーバーだと遅くなりますか

利用者から物理的に遠いサーバーほど、やり取りに時間がかかります。日本の利用者が中心なら、国内のサーバーのほうが有利です。

海外のサーバーを使う場合は、利用者の近くから配信する仕組みを組み合わせる方法もあります。ただし、設定の手間が増えるため、まずは今の数値で困っているかを確かめてください。困っていないなら、急いで変える必要はありません。

TTFBは、どれくらいの頻度で確かめればいいですか

テーマやプラグイン、サーバーの設定を変えたときに確かめれば十分です。何も変えていないのに、毎日測る必要はありません。

月に1度、Search Consoleで不良が出ていないかを見る程度で足ります。不良が出たときに、この記事の切り分けの手順で原因を探してください。数値は、日付と一緒に記録しておきます。変化に気づいたら、その日に何を変えたかを思い出せるようにしておきましょう。

まとめ

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

TTFBはCore Web Vitalsの指標ではないため、LCPが基準内なら直す優先度は下がります。直すときは、リダイレクト、1行のファイルとの比較、テーマとプラグインの順に切り分けてください。サーバーの移転は、原因がサーバーだと確定してから考えます。

まずはPageSpeed Insightsで、実測値のTTFBとLCPを並べて見てください。