TTFBとは、ページの遅さがサーバーの返事待ちによるものかどうかを切り分けるために、ページを開いてから最初のデータが返り始めるまでを測る指標である。表示速度を測る指標はいくつもあるが、TTFBはそのうち最も手前、まだ画面に何も出ていない区間だけを受け持つ。
たとえば、記事ページを開いてから3秒間、画面が真っ白なままだったとする。TTFBが2.5秒なら、その3秒のほとんどはサーバーの返事を待っていた時間である。画像を軽くしても、スクリプトを減らしても、この2.5秒は縮まらない。
白い画面のどこまでが待ち時間か
TTFBが答えるのは、その遅さが返事を待っている時間なのか、返事が来たあとの時間なのか、という切り分けである。
最初のデータとは、サーバーが返す応答の先頭1バイト、つまりいちばん小さい単位のひとかけらを指す。中身が全部そろう必要はない。先頭が届いた瞬間に計測が止まるので、TTFBは「サーバーが口を開くまでの時間」に近い。
この待ち時間はひとつの作業ではなく、Googleのweb.devによるといくつかの区間の合計にあたる。長かったときに疑う先は次の順に並ぶ。
- 転送先の付け替え：入力されたURLから別のURLへ飛ばす設定があると、そのたびに往復が1回増える
- 住所の割り出し：ドメイン名から実際のサーバーの居場所を調べる工程で、初回の訪問ほど時間がかかる
- 接続と暗号化の取り決め：通信を始める前に、相手と手順や鍵をやり取りする往復が入る
- サーバー内の処理：データベースへの問い合わせやページの組み立てで、動的に作るページほど長くなる
Googleが示す目安は、利用者の4分の3にあたる範囲で0.8秒以下である。1.8秒を超えると遅いほうに入る。
ただしTTFBは、Googleが快適さの基準として選んだ3つの指標（Core Web Vitals）には含まれない。Google自身が「必ずこの目安を満たす必要はない」と書いている。順位を競う数字ではなく、他の指標が遅い理由を探すための手がかりという位置づけになる。
語源・提唱者
TTFBという言い方そのものは、サーバーの応答の速さを測るネットワークの用語として以前からあった。これを表示速度の改善に使う道具へ変えたのは、2000年代半ばのWebパフォーマンス改善の現場である。
当時、遅いサイトを速くしようとする担当者の手元には、ページが表示し終わるまでの秒数という数字が1つあるだけだった。その秒数が長いとき、原因がサーバー側にあるのかブラウザ側にあるのかを分ける手立てがない。結果として、画像を軽くする作業から始めてみて、当たらなければ次を試すという進め方になっていた。
Yahoo!にいた Steve Souders らが狙ったのは、この一本の秒数を、原因の在りかで割れるようにすることである。最初の1バイトが返るまでをサーバー側、それ以降をブラウザ側と決めた。この分け方で主要なサイトを測ると、利用者が待つ時間のうち8〜9割をブラウザ側が占めていた。ここから「まずフロントエンド（ブラウザ側）から手を付けよ」という指針が生まれ、2007年の著書と計測ツールを通じて広まった。
割り方が定まったことで、TTFBはサーバー側の持ち時間を表す共通の物差しになった。2010年にGoogleが表示速度を検索順位の要素に加えると発表したことで、エンジニア以外もこの数字を口にするようになる。広まった理由は、この境目が特定の言語や構成に縛られていなかったところにある。どんな作りのサイトでも、最初の1バイトが返る瞬間は必ず1回だけ訪れる。
直す場所を勘で決めなくなる
TTFBを見る効果は、速度改善の作業を始める前に、手を入れる場所が決まることである。
見ないまま進めると、表示が遅いという声に対して、画像の圧縮やスクリプトの整理から着手することになる。数日かけて配信するデータを半分にしても、体感がほとんど変わらない。原因が1件のデータベース問い合わせにあったと分かるのは、その後である。作業そのものは正しくても、順番を間違えたぶんが空振りになる。
先にTTFBを見ておけば、その数秒が返事待ちに入っているかどうかが最初に分かる。0.8秒を大きく超えていればサーバー側から、収まっていればブラウザ側から着手する。どちらに人手を割くかを、感覚ではなく数字で決められる。
効きどころは3つに分かれる。利用者から見れば、何も表示されない時間が短くなる。開発チームから見れば、フロントエンドとバックエンドのどちらの担当が動くかが決まる。事業から見れば、Googleが表示速度を順位の要素に含めている以上、検索からの流入にも関わってくる。
ただし、TTFBを下げること自体を目的にすると外す。中身がそろう前に応答の先頭だけ返せば数字は下がるが、利用者が待つ時間は変わらない。Googleの解説も、キャッシュや103 Early Hints（先に読み込むべきファイルを予告する仕組み）が遅いサーバーを覆い隠す可能性に触れている。TTFBは目標値ではなく、利用者が体感する表示の指標が遅い理由を探すときの入口として扱う。
遅い原因をまず2つに割る
TTFBが登場するのは、表示速度の改善に着手する運用の段階と、リリース前に速度を確かめる検証の段階である。
残るアウトプットは、区間ごとの内訳を並べた1枚の記録になる。この内訳が、そのまま次の作業指示になる。
転送先の付け替えが2回入っていれば設定を削る。サーバー内の処理が長ければ問い合わせを見直す。利用者との距離が遠ければ、利用者に近い場所からファイルを返すCDNを挟む。
この判断はバックエンドやインフラの担当と組んで行う。TTFBはフロントエンド側の作業ではほとんど動かないので、画面を作る担当だけで抱えると打ち手が出てこない。
測り方でつまずくことが多い。自分の端末で1回だけ測った数字は、回線もサーバーとの距離も社内の条件に寄っているので、利用者の実感とずれる。2回目の測定はキャッシュが効いて短く出るため、速くなったと誤解しやすい。実際の訪問から集めた数字を使い、平均ではなく利用者の4分の3が収まる値で見る。
会議でも同じ順番が使える。「サイトが遅い」という漠然とした議題が出たら、まずTTFBの数字を1つ置く。どこを直すかの話は、そのあとで自然に片側へ寄る。
関連用語
- Core Web Vitals
- CDN
