TTFBとは？良い値の目安と改善方法

Time to first byte（TTFB）は、ナビゲーションの開始からHTMLレスポンスの最初のバイトが届くまでの時間です。Googleのweb.devは、実際の訪問の75パーセンタイルで0.8秒以下を良好、1.8秒超を不良としています（web.dev、2025年11月更新）。TTFBはCore Web Vitalsではありませんが、First Contentful PaintやLargest Contentful Paintを含め、後続のすべての指標はTTFBの後に始まります。スマートフォンでは、リダイレクト、DNS、TLS、遅いサーバーが積み重なる場所でもあります。これらの各ステップはモバイル回線で少なくとも1往復の通信を要するためです。

TTFBとは何か

TTFBは、ドキュメントの最初のバイトが届くまでのすべての工程の合計です。リダイレクト、DNS、TLSを含みます。web.devによると、次が含まれます。

• リダイレクトの時間。
• サイトにサービスワーカーがある場合は、その起動時間。
• DNSの名前解決。
• 接続とTLSのネゴシエーション。
• レスポンスの最初のバイトまでのリクエスト自体。

そのため、サーバーが速くてもTTFBは遅く表示されることがあります。http://example.comで始まり、https://example.com、さらにhttps://www.example.comへとリダイレクトされる訪問では、最終ページのサーバーが何かをする前に、2回のリダイレクトと3回の接続を経ています。

TTFBは、古いLighthouseのレポートにあった「サーバー応答時間」とも同じではありません。その監査はメインのドキュメントの待ち時間だけを測り、DNSの名前解決とリダイレクトを除外していたので、TTFBの一部にすぎません（Chrome for Developers）。

良いTTFBとは

良いTTFBは0.8秒以下です。web.devはこの閾値を「大まかな目安」と呼び、要件とはしていません。2025年11月時点の範囲と、より厳しいLighthouseの数値は次のとおりです。

2つの数値は測っているものが違います。Lighthouseの600msはサーバー自身の応答時間を対象とし、0.8秒の目安はTTFB全体を対象とします。そのため、同じページでも一方に合格し、もう一方に不合格になることがあります。どちらもGoogleが定めた設計上の閾値です。

スマートフォンで良い評価を得ている割合はどのくらいでしょうか。HTTP Archiveの2025年版Web Almanac（2025年7月のデータに基づく）によると、モバイルサイトの44%が良いTTFBで、デスクトップの55%より低い結果でした。モバイルでは40%が改善を必要とし、17%が不良でした（Web Almanac 2025、Performance）。

スマートフォンでTTFBが高くなる理由

スマートフォンでTTFBが高くなるのは、最初のバイトより前の各ステップが往復通信であり、モバイル回線での往復は有線より時間がかかるからです。コールドな接続での初回のHTTPS訪問では、次の順序になります。

1. DNSの名前解決で、サーバーのアドレスを調べる。
2. TCPハンドシェイク：サーバーとの往復が1回。
3. TLSハンドシェイク：TLS 1.3ではさらに1往復。RFC 8446は「1-RTTハンドシェイク」と呼んでいます。
4. HTTPリクエストとレスポンスの最初のバイト：1往復に加え、サーバーの処理時間。

つまり、ネットワークだけでサーバーとの3往復とDNS解決がかかり、その後にサーバー自身の処理が続きます。次の表は、説明のために選んだ2つの往復時間（RTT）による計算であり、実際のネットワークの計測値ではありません。

RTTが長い場合、400msで応答するサーバーでも、DNSを加えると0.8秒の目安を超えてしまいます。サーバーに問題があるわけではなく、接続の準備で予算の半分以上を使ってしまうのです。

この負荷を減らす方法は2つあります。接続を再利用することです。再訪問したユーザーが接続を保っていれば、ステップ1〜3は省略されます。もう1つは新しいプロトコルを使うことです。HTTP/3はQUIC上で動作し、そのハンドシェイクは「暗号化パラメータとトランスポートパラメータの交渉を組み合わせる」（RFC 9000、2021年5月）ため、TCPにTLSを重ねる方式より往復回数が少なくなります。web.devは、CDNがHTTP/2やHTTP/3などの最新プロトコルでコンテンツを配信すると述べています（web.dev）。

スマートフォン特有の原因として、別のモバイル用サイトもあります。リダイレクトに関するLighthouseの助言では、モバイルユーザーをモバイル用ページにリダイレクトするよりも、レスポンシブデザインを検討すべきとされています（Chrome for Developers）。レスポンシブのアプローチはモバイル対応サイトの作り方で説明しています。

TTFBの測り方

TTFBは、ラボとフィールドの2通りで測ってください。ラボでは時間の内訳を見るため、フィールドでは実際のスマートフォンでの値を見るためです。2つの数値は一致しないことがあります。ラボの実行は1台のマシンでの1回の読み込みですが、フィールドの値は実際の訪問の75パーセンタイルです。

DevTools（ラボ）では、Networkパネルを開いて再読み込みし、最初のリクエスト（ドキュメント）を選んでTimingタブを開きます。フェーズはQueueing、Stalled、DNS Lookup、Initial connection、Request sent、Waiting（TTFB）です。「Waiting（TTFB）」は、1往復にサーバーの準備時間を加えたものです（Chrome DevToolsのリファレンス）。Initial connectionのバーが長く、Waitingが短い場合は、アプリケーションではなく接続の準備を直す必要があります。

ページ上（フィールド）では、web-vitalsライブラリがTTFBを報告し、その帰属ビルドでは同じフェーズに分解します。ドキュメント（web-vitalsのREADME）では、waitingDuration（リクエスト前のリダイレクトとブラウザの処理）、cacheDuration（キャッシュの確認とサービスワーカーの時間）、dnsDuration、connectionDuration、requestDuration（ネットワーク時間とサーバー処理）と名付けられています。

import {onTTFB} from 'web-vitals/attribution';

onTTFB(({value, rating, attribution}) => {
  // 分析用のエンドポイントに送信してください。ここではコンソールに内訳を出力しています。
  console.log(rating, Math.round(value), {
    redirectsAndWaiting: attribution.waitingDuration,
    cache: attribution.cacheDuration,
    dns: attribution.dnsDuration,
    connection: attribution.connectionDuration,
    request: attribution.requestDuration,
  });
});

デバイス別（フィールド、コードなし）には、Chrome UX Report APIでformFactorにPHONE、TABLET、DESKTOPを指定すると、experimental_time_to_first_byte（APIの実験的な指標）の75パーセンタイルが得られます（CrUX APIのドキュメント）。データは28日間の移動平均です。スマートフォンのTTFBがデスクトップより悪いかどうかを素早く確認する方法です。より広範な速度テストの実行方法はモバイルページ速度テストのガイドに、LighthouseがTTFBを同じ問題として報告する方法はLighthouseでのモバイル監査ガイドにあります。

サーバー側では、Server-Timingヘッダーを追加して、どのバックエンドの工程が遅いかを確認できます。Chrome 65、Firefox 61、Safari 16.4が対応しています（MDN browser-compat-data 8.1.7、2026年10月）。

Server-Timing: db;dur=53, app;dur=47.2, cache;desc="miss"

これらの値は、Networkパネルの Timingタブと、上記の帰属オブジェクトのnavigationEntry.serverTimingに表示されます。

TTFBを改善する方法

内訳で最も大きいフェーズから始めてください。修正はそれぞれ、対応するフェーズにしか効かないからです。次の表は、見えている症状と変更すべき箇所を対応させています。

以下の対策は、web.devのTTFB最適化ガイド（web.dev、2025年11月更新）に従っています。

1. リダイレクトを減らす。web.devは、同一オリジンの301や302リダイレクトを取り除くよう勧めています。例としては、https://の付け忘れや末尾のスラッシュの不一致があります。また、広告主やニュースレターには最終URLを渡すよう勧めています。HSTSは、ブラウザにhttp://を最初に要求せずhttps://を直接使わせます。
2. 前段にCDNを置く。CDNは訪問者に近いエッジサーバーから応答するため、上の表の各往復が短くなります。web.devによると、HTTP/3、TLS 1.3、圧縮も通常ついてきます。
3. HTMLをキャッシュする。すべての訪問者に同じページなら、Cache-Controlでキャッシュし、アプリケーションに触れずに配信できます。web.devは、短いキャッシュ時間でも訪問の多いサイトには効果があると述べています。診断中は、URLにパラメータを付けてキャッシュを迂回してください。
4. サーバーの処理を減らす。Lighthouseの推奨は、アプリケーションのロジックとデータベースのクエリを最適化し、必要ならハードウェアを強化し、エッジでキャッシュできるドキュメントにはCDNを使うことです。まずServer-Timingで遅い工程を見つけてください。
5. テキストを圧縮する。Lighthouseのインサイトは、圧縮されずに送られるメインドキュメントを指摘します。ブラウザはAccept-Encodingで受け入れ可能な方式を伝え、サーバーはContent-Encodingで応答します。
6. HTMLをストリーミングする。web.devは、レスポンスのストリームを流し続け、可能であればストリーミングのサーバーレンダリングや静的レンダリングを使い、最初のバイトを早く送るよう勧めています。早期フラッシュもresponseStartとして計測されるため、TTFBは体感より良く見えることがあります。First Contentful Paintも確認してください。
7. 103 Early Hintsを送る。サーバーがページを組み立てるのに時間がかかる場合、まずLinkヘッダー付きの103レスポンスを送れます。ブラウザは待っている間にpreconnectやpreloadを開始できます。

HTTP/2 103
Link: </css/app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/2 200
content-type: text/html

Early Hintsは、ほとんどのブラウザでHTTP/2以降で動作し、最初の103レスポンスだけが処理されます（MDN、2026年6月）。対応はChrome 103、Firefox 120、Safari 17からです。103レスポンスはTTFBでは最初のバイトとして扱われます。また、ChromeはresponseStartが示す時刻を変更しています（Chrome 115では最終レスポンス、Chrome 133では再び最初のバイト）。そのため、ツール間でTTFBを比較するときは注意してください（web.dev）。

サイトにサービスワーカーがある場合、シェルをキャッシュから配信すると、再訪問時のTTFBも短くなります。web.devは、あまり変わらない資産にはstale-while-revalidate、個別化されたHTMLにはネットワーク優先を勧めています。

静的サイトとCMSのサイト

静的サイトは理想的な状況にあります。HTMLはリクエスト前に存在するため、TTFBの大部分は接続の準備であり、主な対策はCDNです。CMSはリクエストのたびにページを組み立てるため、最大の効果はページ全体のキャッシュにあります。WordPressについては、Lighthouseのドキュメントが軽量なテーマ、ページ全体のキャッシュ、プラグインの削減を挙げています。Drupalはページキャッシュ、PHPのOPcache、RedisまたはMemcachedです。MagentoはVarnishです（Chrome for Developers。2019年の最終更新で、Lighthouse 13より前の内容です）。

別のAMP用URLは、正規版と内容を揃えて維持すべきもう1つのページバージョンになります。それがまだ必要かどうかは2026年のAMPで扱っています。

スマートフォン幅のページでリダイレクトの連鎖を確認する

リダイレクトは、ストップウォッチなしで見つけられる唯一のTTFBの原因です。スマートフォンはPCとは別の場所に転送されることがあるからです。Mobile View Extensionは、タブをスマートフォンのユーザーエージェント、画面サイズ、ピクセル比で読み込み直すので、どのURLに到達するか、モバイル版ページが実際のモバイル版として読み込まれるかを確認できます。ただし、TTFBや速度の指標は測定できず、PCの回線とハードウェアで動作します。実機での計測には、上で紹介したフィールドのツールを使ってください。

よくある質問

良いTTFBは何秒ですか？

web.devによると（2025年11月）、75パーセンタイルで0.8秒以下が良好で、1.8秒を超えると不良です。これは大まかな目安であり、TTFBはCore Web Vitalsには含まれません。

TTFBはCore Web Vitalsですか？

いいえ。Core Web Vitalsは、Largest Contentful Paint、Interaction to Next Paint、Cumulative Layout Shiftです。web.devは、TTFBはそこに含まれないと明言しています。ただし、TTFBが高いとFirst Contentful PaintやLargest Contentful Paintが遅れるため、重要です。

LighthouseとフィールドデータでTTFBが違うのはなぜですか？

Lighthouseは回線を制限した状態で1台のマシンで1回読み込みますが、フィールドデータは実際のネットワークとキャッシュでの実際の訪問を対象とします。フィールドの値を信頼し、ラボの実行は遅いフェーズを見つけるために使ってください。

TTFBはSEOに影響しますか？

web.devは、TTFBはCore Web Vitalsではないものの、First Contentful Paintより前にあるため、TTFBが遅いと後続の指標、特にLargest Contentful Paintが遅れると述べています。まずそれらの指標を改善し、TTFBを使って遅さの原因を見つけてください。