先に要点
- TTFB(Time To First Byte)とは、ブラウザがリクエストを送ってから、サーバーの応答の最初の1バイトを受け取るまでの時間 です。`サーバーが返事を始めるまでの待ち時間` と考えると分かりやすいです。
- 目安は 800ミリ秒以下なら良好、1.8秒を超えると要改善(Google の基準)。TTFB が遅いと、そのぶん表示全体が後ろにずれます。
- 遅くなる主因は サーバーやデータベースの処理時間・サーバーまでの物理的な距離(レイテンシ)・キャッシュ未活用・余計なリダイレクト の4つに集約されます。
- 改善の基本は キャッシュ・CDN・バックエンド高速化・リダイレクト削減。とくに CDN とキャッシュは効果が大きいです。
サイトの表示が遅い を調べていくと、必ず出てくるのが TTFB という指標です。Time To First Byte の略で、表示速度のボトルネックがどこにあるかを切り分ける入口になる数字です。
TTFB は、ひとことで言うと 「リクエストを送ってから、サーバーの応答の最初の1バイトが返ってくるまでの時間」 です。画像やスクリプトの読み込みより前、サーバーが返事を始めるまで の待ち時間を表します。ここが遅いと、後続の処理がどれだけ速くても、全体の表示が必ずその分だけ遅れます。
この記事では、TTFB の意味、何ミリ秒なら良いのかの目安、遅くなる原因、測り方、改善方法、そして Core Web Vitals との関係までを、実務で切り分けに使える形で整理します。
TTFBとは何か
TTFB は、ブラウザがページをリクエストしてから 最初の1バイトを受信するまで の時間です。ページが表示し終わるまで ではなく、サーバーが応答を返し始めるまで を測る点がポイントです。
この数字は、内部的にはいくつかの段階の合計でできています。
| 段階 | 内容 |
|---|---|
| リダイレクト | 転送が挟まると、その往復ぶん時間が増える |
| DNS 解決 | ドメイン名から IP アドレスを引く時間 |
| 接続 + TLS | サーバーへの接続確立と暗号化(HTTPS)のハンドシェイク |
| サーバー処理 | アプリやデータベースが応答を組み立てる時間(ここが一番大きくなりやすい) |
つまり TTFB は 「ネットワークの往復」と「サーバー側の処理時間」の合算 です。改善するときは、このどちらがボトルネックなのかを切り分けるのが第一歩になります。
良いTTFBの目安は何ミリ秒か
Google は TTFB の目安を次のように示しています。あくまで参考値で、サイトの性質によって現実的なラインは変わりますが、判断の基準として有効です。
良好
800 ミリ秒以下。ここに収まっていれば、TTFB が表示速度の足を引っ張っている可能性は低い。
要改善
1.8 秒超。ユーザーが体感で遅さを感じやすく、検索評価にも影響しうる。優先的に対処する。
注意したいのは、TTFB は計測する場所によって大きく変わる ことです。サーバーの近くから測れば速く、地球の反対側から測れば遅く出ます。どこから来るユーザーを対象にするか を決めて評価するのが実務的です。
TTFBが遅くなる主な原因
TTFB が大きいとき、原因はだいたい次の4つに収まります。
サーバーまでの距離(レイテンシ)
ユーザーとサーバーが物理的に遠いほど、往復に時間がかかる。海外サーバーに国内からアクセスすると、それだけで数百ミリ秒増えることもある。
余計なリダイレクト
httpからhttpsへ、wwwあり/なしの統一などで転送が複数回挟まると、その往復ぶん TTFB が増える。
切り分けのコツは、「サーバー処理が重いのか、ネットワーク距離が遠いのか」をまず分ける ことです。サーバーのすぐ近く(同じデータセンター内など)から測った TTFB が速いなら、原因はネットワーク距離側。近くから測っても遅いなら、サーバー・DB 側が原因です。
TTFBの測り方
TTFB は複数の方法で測れます。用途に応じて使い分けます。
実務では、まずサーバーの近くから測ってサーバー処理時間を把握し、次に実ユーザーの地域から測ってネットワーク込みの値を見る という二段構えが有効です。前者が遅ければバックエンド、後者だけ遅ければ配信(距離)が課題、と切り分けられます。curl -w "%{time_starttransfer}\n" -o /dev/null -s https://example.com のように書くと、応答が始まるまでの秒数だけを取り出せます。
TTFBを改善する方法
原因の切り分けができたら、効く順に手を打ちます。
優先順位としては、キャッシュと CDN が費用対効果の高い二大対策 です。アプリの作り込みに手を入れる前に、まず キャッシュできるものをキャッシュしているか CDN でエッジから返せているか を確認すると、少ない労力で TTFB を縮められることが多いです。CDN の要否そのものは CDNとは？何が速くなるのか も参考になります。キャッシュ層の選択肢は Redisのキャッシュ・セッション・キュー で整理しています。
Core Web Vitalsとの関係
TTFB は単独の指標であると同時に、LCP(Largest Contentful Paint)の一部 でもあります。LCP は メインコンテンツが表示されるまでの時間 で、Core Web Vitals の中心的な指標です。
LCP は大まかに TTFB + コンテンツの読み込み・描画 で構成されるため、TTFB が遅いと、画像やCSSをどれだけ最適化しても LCP の下限が上がってしまう という関係があります。画像を軽くしたのに LCP が縮まらない というときは、TTFB が足を引っ張っているケースが少なくありません。
Core Web Vitals 全体の改善手順は Core Web Vitals 改善の実践ガイド にまとめているので、TTFB を縮めたあとの次の一手はそちらを参照してください。
TTFBに関するよくある質問
Q. TTFB は何ミリ秒以下を目指せばいいですか？
A. Google の目安では 800 ミリ秒以下が良好、1.8 秒超が要改善です。ただし計測地点によって変わるため、主要なユーザーの地域から測って 800 ミリ秒以下 を一つの目標にすると現実的です。サーバーの近くから測る値はそれよりかなり速く出ます。
Q. TTFB と表示速度(ページの読み込み完了)は違うものですか？
A. 違います。TTFB は サーバーが応答を返し始めるまで の時間で、ページ全体の表示完了はその後に続く画像やスクリプトの読み込みまで含みます。TTFB は表示速度の スタート地点 を決める指標だと考えてください。
Q. TTFB が遅いのはサーバーが悪いからですか？
A. 必ずしもそうとは限りません。サーバー・DB の処理が重い場合もあれば、ユーザーとサーバーの物理的な距離が遠い(レイテンシ)場合もあります。サーバーの近くから測って速いなら距離が原因、近くから測っても遅いならサーバー処理が原因、と切り分けます。
Q. CDN を入れると TTFB は必ず速くなりますか？
A. キャッシュ可能なコンテンツでは大きく効きます。エッジから返せるぶんネットワーク距離が縮まるためです。ただし、毎回サーバーで生成する動的ページで CDN を素通りさせている場合は、効果が限定的になります。何をエッジでキャッシュするか の設計が重要です。
Q. WordPress で TTFB が遅いときはどうすればいいですか？
A. まずページキャッシュ系のプラグインや、サーバー側のキャッシュを有効にするのが効果的です。毎回 PHP と DB でページを生成していると TTFB が伸びるため、生成済みHTMLを返す形にするだけで大きく改善することが多いです。あわせて CDN の導入も検討します。
Q. TTFB はSEOに影響しますか？
A. 直接の順位指標ではありませんが、TTFB は LCP の一部であり、LCP は Core Web Vitals としてページ体験の評価に関わります。TTFB が遅いと LCP も悪化しやすいため、間接的に検索評価へ影響しうると考えておくのが妥当です。
Q. 開発者ツールの TTFB と計測サービスの値が違うのはなぜですか？
A. 計測する場所とネットワーク条件が違うためです。手元のブラウザは自分の回線とサーバーまでの距離の影響を受け、計測サービスは各地の計測地点や実ユーザーデータ(CrUX)に基づきます。1つの値で判断せず、どこから測った値か を意識して比較します。
参考リンク
- web.dev: Time to First Byte (TTFB)
- MDN: Time to First Byte
- Google: Core Web Vitals