初回バイトまでの時間 (TTFB)

TL;DR — Time to First Byte（TTFB）とは、ブラウザがページをリクエストしてから、応答の最初の1バイトが返ってくるまでの待ち時間のことです。サーバーの応答性を示す指標です。良好なTTFBは0,8秒以下です。これはCore Web Vitalsではありませんが、遅いTTFBはCore Web Vitalsの指標を悪化させます。最初の1バイトが届くまで、ページ上の何も開始できないからです。

TTFBとは

リンクをクリックすると、ブラウザはサーバーにリクエストを送信して待機します。Time to First Byte（TTFB） は、その待ち時間の長さです。リクエストが開始されてから、応答の最初のバイトが届き始めるまでの時間です。

これは単に「サーバーがどれだけ速く処理するか」というだけではありません。ブラウザが正しいマシンに接続する前に、多くの処理が行われます。リダイレクトに従う、DNSでドメインを検索する、接続を開く、セキュア（TLS）ハンドシェイクをネゴシエートするなどです。TTFBはこれらすべてを合計し、さらにサーバー自身の処理時間を加え、最初のバイトが返ってきた時点で計測を終了します。

良好とされる基準

Googleのweb.devガイダンスはシンプルです。TTFBを0,8秒以下にすることを目指しましょう。1,8秒を超えると不良と見なされます。ほとんどのサイトは良好な基準を達成できるはずですが、実際には多くのサイトが達成できていません。だからこそ確認する価値があるのです。

「コア」指標ではないのに重要な理由

Core Web Vitals（LCP、INP、CLS）についてはよく耳にするでしょう。TTFBはその中には含まれません。しかし、読み込みに関する指標の下位に位置しています。First Contentful PaintとLargest Contentful Paintの両方が、その計測にTTFBを含んでいます。ブラウザはバイトが届き始めるまで何も描画できません。したがって、TTFBが遅いと、ページが体感できる速度に上限が設けられることになります。

実用的な要点：TTFB自体がランキングを上げるわけではありませんが、悪いTTFBは、ランキングに影響する指標を静かに引き下げます。

一般的な修正方法をわかりやすく説明

• CDNを使用する。 サイトのコピーを訪問者に物理的に近いサーバーに配置するため、往復時間が短くなります。
• ページをキャッシュする。 サーバーが毎回ページを再構築する代わりに、既製のコピーを返せれば、最初のバイトがはるかに早く届きます。
• より良いホスティングを利用する。 より高速なサーバーとデータベースが最も直接的な修正です。
• リダイレクトを減らす。 リダイレクトは、実際のページの読み込みが始まる前の余分な往復です。

完全版（正確なしきい値、LCPとの関係、LighthouseとCrUXのしきい値の混乱、Early Hints、測定方法）が必要ですか？詳細タブに切り替えてください。

TL;DR — TTFBは、リクエストの開始から応答の最初のバイトが届くまでの時間です。リダイレクト時間、サービスワーカーの起動、DNSルックアップ、接続とTLSネゴシエーション、そして最初のバイトまでのリクエスト自体の合計です。これはCore Web Vitalではありません。FCPとLCPに影響を与える、基礎的で診断的な指標です。web.devによると、良好は≤0,8秒、不良は>1,8秒（75パーセンタイル）です。フィールド指標とラボ指標の両方です。Lighthouseの「サーバーの応答時間の短縮」監査はより狭く、約600msを超えるサーバー時間をフラグしますが、完全なTTFBではありません。Lighthouse 13以降は「ドキュメントリクエストの遅延」インサイト内にあります。CDN、エッジ/HTMLキャッシュ、より高速なホスティング、リダイレクトの削減、103 Early Hints、効率的なTLSで修正します。また、TTFBが高いからといって、必ずしもサイトが遅いとは限りません。

TTFBが実際に測定するもの

TTFBは、ページへのナビゲーションを開始してから、応答の最初のバイトが届き始めるまでの時間を測定します。よくある誤解は、これを純粋なバックエンド処理時間と見なすことです。そうではありません。最初のバイトが返ってくる前に完了しなければならないすべての合計です。

1. リダイレクト時間
2. サービスワーカーの起動時間（該当する場合）
3. DNSルックアップ
4. 接続とTLSネゴシエーション
5. リクエスト — 応答の最初のバイトが届くまでの間

サーバー処理も含まれますが、接続確立のオーバーヘッド全体も含まれます。この違いは、ツールを使い始めた瞬間に重要になります。なぜなら、すべてのツールが同じ部分を測定しているわけではないからです（詳細は後述）。

Core Web Vitalsではない

最も一般的な誤解なので、はっきり言います。TTFBはCore Web Vitalsではありません。 3つのCore Web Vitalsは、LCP（読み込み）、INP（インタラクティブ性）、CLS（視覚的安定性）です。TTFBは基礎的な診断指標であり、Google自身の説明では「ラボとフィールドの両方で、接続確立時間とWebサーバーの応答性を測定するための基礎的な指標」です。

Googleはまた、優れたTTFBのしきい値を厳密に満たす必要はないと明言しています。Core Web Vitalではないため、「重要な指標で良いスコアを獲得する能力を妨げない限り、サイトが『良好』なTTFBのしきい値を満たすことは絶対に必要ではない」としています。最後の節がポイントです。ほとんどのサイトでは、悪いTTFBは確実に重要な指標を妨げます。

FCPとLCPをどのように制限するか

TTFBは、すべてのユーザー中心の読み込み指標に先行します。First Contentful PaintとLargest Contentful Paintの両方が、その測定にTTFBを含みます。これらの指標の時計は、最初のバイトを待っている間にすでに動いています。web.devはLCPをサブパートに分割しており、TTFBはその最初のものです。そのため、遅いTTFBの上に速いLCPを置くことはできません。

ここで実際のデータが重要になります。HTTP ArchiveのWeb Almanacは、悪いLCPのサイトでは、TTFBだけで約2,27秒を消費していることを発見しました。これは、画像やテキストがレンダリングを開始する前に、2,5秒の「良好なLCP」予算のほぼ全体に相当します。LCPが悪く、ページ上のコンテンツが最適化されているように見える場合、最初に確認するのはTTFBです。

したがって、ランキングへの影響は間接的ですが現実的です。TTFBはGoogleのランキングシグナルではありません（ランキングシグナルはLCP、INP、CLSであり、TTFBはそのセットに含まれていません）。しかし、TTFBはLCPに組み込まれており、LCPはランキングシグナルです。経路はLCPを通り、TTFBを直接通りません。

しきい値：良好、改善が必要、不良

web.devのガイダンス。実際のユーザーの読み込みの75パーセンタイルで測定：

• 良好： ≤ 0,8秒
• 不良： > 1,8秒

「ほとんどのサイトは、TTFBを0.8秒以下にするよう努めるべきです。」歴史を知っておく価値があります。Googleは2022年に「良好」の基準を500ミリ秒から800ミリ秒に変更し、古いデータは新しい基準で再計算されました。そのため、生の過去のTTFB数値を比較する際は、どのしきい値が使用されたかを確認せずに比較しないでください。

600ミリ秒と800ミリ秒の混乱

これは多くの人を混乱させるので、正確に述べる価値があります。2つの異なる数値が存在します：

• CrUX / web.devのTTFBしきい値：800ミリ秒。 これは完全なTTFB（DNS + 接続 + TLS + リダイレクト + サーバー時間）のフィールドしきい値です。
• Lighthouseの「サーバー応答時間の短縮」監査：約600ミリ秒。 これは、ブラウザがメインドキュメントリクエストに対してサーバーが応答するのを約600ミリ秒以上待つ場合にフラグを立てるラボ監査です。重要なのは、サーバー応答時間のみを測定することです。DNS、接続確立、TLSは含まれません。

したがって、Lighthouseの数値はより厳しく見えますが、より狭い範囲を測定しています。ドキュメントが述べるように、「サーバー応答時間は、完全なTime to First Byte（TTFB）の一部にすぎません。」Lighthouse監査の合格をフィールドTTFBが良好である証拠として扱わないでください。また、600 < 800がしきい値の矛盾を意味するとパニックにならないでください。それらは異なるものを測定しています。

バージョンに関する注意：Lighthouse 13の時点で、この監査は単独では存在せず、より広範な「ドキュメントリクエストの遅延」インサイトに統合されています。基礎となる約600ミリ秒のサーバー応答チェックは同じですが、レポートを生成したLighthouseのバージョンによって表示方法が異なります。

フィールドとラボ — 両方

TTFB は、両方の世界で確認できる指標の一つです。フィールドでは、CrUX（実際の Chrome ユーザー）から取得され、PageSpeed Insights や Search Console に表示されます。ラボでは、Chrome DevTools のネットワークパネルのウォーターフォールに「Waiting (TTFB)」と表示され（「ブラウザがレスポンスの最初のバイトを待っている」）、WebPageTest や Lighthouse などのツールでも報告されます。フィールドでの注意点の一つとして、CrUX では TTFB はまだやや実験的な扱いであり、プリレンダリングや bfcache ナビゲーションなどの一部の高度なナビゲーションタイプが除外されるため、フィールドの平均値はユーザーが実際に感じる体感よりもやや悲観的に見えることがあります。

TTFB が高いからといって、必ずしもサイトが遅いわけではない

ここに、しきい値の数字が隠しているニュアンスがあります。サーバーサイドレンダリングのページは、クライアントサイドレンダリングのページよりも高い TTFB を記録しても、より良い FCP と LCP を実現できます。なぜなら、最初のバイトがようやく届いたとき、それはブラウザがすぐに描画できる完全な HTML であり、何かを表示する前に JavaScript バンドルを取得して実行する必要がある薄いシェルではないからです。Google はこれを直接述べています。「a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience.」 (翻訳) 「クライアントサイドの作業がそれほど必要ないサーバーレンダリングサイトは、完全にクライアントサイドレンダリングの体験よりも TTFB が高くなる可能性がありますが、FCP と LCP の値は優れている可能性があります。」

逆の側面：クライアントサイドレンダリングのシングルページアプリケーションの場合、TTFB によって JavaScript バンドルの読み込みが開始されるタイミングが決まるため、低い TTFB はそこではより重要であり、重要でなくなるわけではありません。TTFB を単独で最適化しないでください。読み込みチェーン全体を最適化し、TTFB が FCP と LCP に与える影響で判断してください。

TTFB を改善する方法

おおよそ優先順位の高い順に：

• まずはホスティングから。 バックエンドやデータベースのクエリが遅いと、すべてのリクエストにコストがかかります。フロントエンドの作業ではこれを取り除くことはできません。これが最初に検討すべきことです。
• CDN を使用する。 CDN は近接性の問題を解決します。エッジサーバーの分散ネットワークがリソースをユーザーの物理的に近い場所にキャッシュし、接続と TLS ハンドシェイクの光速によるコストを削減します。これはほとんどのサイトにとって最も ROI の高い修正です。なぜなら、オリジンからの地理的な距離は、バックエンドでは消せない構造的なコストだからです。注意点：キャッシュできない完全に動的でパーソナライズされたコンテンツの場合、CDN はキャッシュヒットのメリットなしにホップを追加します。その場合は、バックエンドの最適化、エッジコンピューティング、またはストリーミングが答えです。
• HTML をキャッシュする。たとえ短時間でも。 短いキャッシュ時間でも、混雑するサイトでは顕著に効果があります。その時間枠内の最初の訪問者だけがオリジンまでの完全なレイテンシを支払い、他の全員はキャッシュされたコピーを取得します。
• リダイレクトを排除する。 リダイレクトは TTFB が高くなる一般的な原因です。それぞれが実際のレスポンスが始まる前のラウンドトリップです。自分で制御できるものを削減しましょう。
• マークアップをブラウザにストリーミングする。 ブラウザは、マークアップが到着したときにチャンク単位でストリーミングされると効率的に処理します。多くの SSR フレームワークはストリーミングをサポートしていますが、オフのままになっています。これをオンにすると、インフラストラクチャの変更なしに動的ページの TTFB を下げることができます。
• 103 Early Hints を使用する。 103 ステータスコードは、バックエンドがまだマークアップを準備している間にサーバーが送信できる予備的なレスポンスであり、ブラウザにレンダリングに重要なリソースのダウンロードを早期に開始するようにヒントを与えます。これは TTFB 自体を下げるわけではありません。実際、103 は「最初のバイト」と見なされる可能性があります。しかし、高い TTFB の影響を縮小します。Shopify と Cloudflare は、これによる LCP の改善が数百ミリ秒、場合によっては 1 秒近くになったと報告しています。
• TLS を効率的にネゴシエーションし、サービスワーカーの起動を最適化する。 まだ起動していないサービスワーカーは、その起動時間を TTFB に追加します。一度実行されると、そのキャッシュ（stale-while-revalidate、または SPA のアプリシェルモデル）は TTFB を劇的に削減できます。

サイトの実際の状況

これが注目に値する理由は、ウェブ全体にわたる根強い問題だからです。Web Almanacのモバイルにおけるgood-TTFB率は、5年間ほとんど動いていません — 約 41〜42%で推移しており、つまり大多数のモバイルサイトは依然として「良好な」TTFBを達成していないことを意味します。率直に言って、その停滞はチャンスです。LCPに失敗しているサーバー負荷の高いサイトにとって、TTFBは通常、最も効果の高い修正策です。

このページはweb-performanceクラスターの一部であり、Core Web Vitalsの下に位置します。TTFBが影響を与える指標については、Largest Contentful Paintと First Contentful Paintを参照してください。実際のユーザーとラボで測定するには、 CrUX、PageSpeed Insights、Lighthouseを参照してください。

AIまとめ

Advancedバージョンの簡潔な見解:

• TTFB = 最初のバイトまでの待ち時間。 リクエスト開始からレスポンスの最初のバイトが到着するまでの時間 — リダイレクト時間、サービスワーカーの起動、DNSルックアップ、接続 + TLSネゴシエーション、そしてリクエスト自体の合計です。単なるサーバー処理時間ではありません。
• これはCore Web Vitalではありません。 Core Web VitalsはLCP、INP、CLSです。TTFBは 基盤となる診断指標です。
• FCPとLCPの上限を決定します。 両方にTTFBが含まれるため、TTFBが遅いとページの読み込み速度に上限が設定されます。LCPが不良のサイトでは、TTFBだけで約2,27秒 — 良好なLCPの予算2,5秒のほぼ全体を占めていました。
• ランキングへの影響：間接的。 TTFBはGoogleのランキングシグナルではありませんが、ランキングシグナルであるLCPに組み込まれています。経路はLCPを通ります。
• しきい値（75パーセンタイル）： 良好 ≤ 0,8秒、不良 > 1,8秒。「良好」の基準線は2022年に500ミリ秒から800ミリ秒に変更されました。
• 600ミリ秒 vs 800ミリ秒： Lighthouseの「サーバーの応答時間の短縮」監査は、サーバー時間のみの約600ミリ秒にフラグを立てます — これは800ミリ秒の完全なTTFBフィールドしきい値よりも狭い範囲です。「サーバーの応答時間は完全なTTFBの一部にすぎません。」Lighthouse 13以降、この監査は「ドキュメントリクエストの待ち時間」インサイト内に含まれています。
• フィールドとラボ： CrUX/PSI/Search Console（フィールド）。DevToolsの「Waiting (TTFB)」、 WebPageTest、Lighthouse（ラボ）。
• 高いTTFB ≠ 遅いサイト： SSRページは、クライアントレンダリングされたページよりも高いTTFBを持つ場合がありますが、最初のバイトが完全なHTMLであるため、FCP/LCPは優れている可能性があります。
• 修正策（優先順位）： まずホスティング、次にCDN、HTMLキャッシュ、リダイレクトの削減、 ストリーミング、103 Early Hints、効率的なTLS、サービスワーカーの起動。
• ウェブの現状： モバイルのgood-TTFBは5年間約41〜42%で横ばい — これは実際のチャンスです。

公式ドキュメント

GoogleのChromeおよびweb.devチームによる一次情報のドキュメント。

• Time to First Byte (TTFB) — 定義、 5つの構成要素、0,8秒 / 1,8秒のしきい値、Core Web Vitalではない理由、および FCPとLCPとの関係。
• Optimize TTFB — 最適化ガイド： まずホスティング、次にCDN、キャッシュ、リダイレクト、ストリーミング、103 Early Hints、および サービスワーカー。
• Reduce server response times — Lighthouse監査（約600ミリ秒のサーバー時間しきい値）と、完全なTTFBとの違い。Lighthouse 13以降は「ドキュメントリクエストの待ち時間」インサイトに統合されています。
• Web Vitals — 指標の分類におけるTTFBの位置づけ： 補足/診断指標であり、LCP、INP、CLSがCore Web Vitalsです。
• Largest Contentful Paint (LCP) — LCPにTTFBの遅延が含まれることを確認。
• First Contentful Paint (FCP) — FCPにTTFBが含まれることを確認し、修正策として「サーバーの応答時間の短縮 (TTFB)」を挙げています。
• Core Web Vitals (Google Search Central) — ランキングシグナルのドキュメントではLCP、INP、CLSのみが挙げられており、TTFBは記載されていません。
• 103 Early Hints — 初期 レスポンスコード、ブラウザ/サーバーのサポート、および実際の結果。

ソースからの引用

Googleのweb.devおよびChromeチームによる公式見解です。各リンクはディープリンクで、検証済みの引用箇所が掲載されているソースページの該当箇所にジャンプします。

web.dev — TTFBとは

• “TTFB is a metric that measures the time between starting navigating to a page and when the first byte of a response begins to arrive.” (翻訳) 「TTFBは、ページへのナビゲーションを開始してから、レスポンスの最初のバイトが到着し始めるまでの時間を測定する指標です。」 引用へジャンプ
• “Time to First Byte (TTFB) is a foundational metric for measuring connection setup time and web server responsiveness in both the lab and the field.” (翻訳) 「Time to First Byte（TTFB）は、ラボとフィールドの両方において、接続確立時間とWebサーバーの応答性を測定するための基礎的な指標です。」 引用へジャンプ

web.dev — しきい値

• “Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds.” (翻訳) 「良好なTTFB値は0.8秒以下であり、不良な値は1.8秒を超えるものです。」 引用へジャンプ

web.dev — Core Web Vitalsではない

• “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold, provided that it doesn’t impede their ability to score well on the metrics that matter.” (翻訳) 「TTFBはCore Web Vitalsの指標ではないため、重要度の高い指標で良いスコアを獲得する能力を妨げない限り、サイトが『良好』なTTFBのしきい値を満たすことは絶対に必要ではありません。」 引用へジャンプ

web.dev — FCPおよびLCPとの関係

• “Because TTFB precedes user-centric metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP)…” (翻訳) 「TTFBは、First Contentful Paint（FCP）やLargest Contentful Paint（LCP）などのユーザー中心の指標に先行するため…」 引用へジャンプ
• サーバーレンダリングサイトの場合: “a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience.” (翻訳) 「クライアント側の処理をあまり必要としないサーバーレンダリングサイトは、完全にクライアントレンダリングされた体験よりもTTFBが高くなる可能性がありますが、FCPとLCPの値は優れている可能性があります。」 (web.dev、“Time to First Byte”)

Lighthouse — サーバーレスポンスタイムと完全なTTFB

• “Server response time is only part of the full Time to First Byte (TTFB).” (翻訳) 「サーバーレスポンスタイムは、完全なTime to First Byte（TTFB）の一部にすぎません。」 (Lighthouse、“Reduce server response times.”)

Patrick Stox — TTFBの位置づけについて (私のAhrefs Core Web Vitalsガイドより)

• “There are additional Web Vitals that serve as proxy measures or supplemental metrics but are not used in the ranking calculations. The Web Vitals metrics for visual load include Time to First Byte (TTFB) and First Contentful Paint (FCP).” (翻訳) 「ランキング計算には使用されないものの、代理指標または補足指標として機能する追加のWeb Vitalsがあります。視覚的な読み込みに関するWeb Vitals指標には、Time to First Byte（TTFB）とFirst Contentful Paint（FCP）が含まれます。」 ガイドを読む

TTFBトリアージチェックリスト

PageSpeed Insights、Search Console、またはLighthouseが遅いサーバーレスポンスをフラグした場合は、このリストを順に確認してください:

• 確認している対象を明確にする — フィールド全体のTTFB（良好は≤0,8秒）か、Lighthouseの「サーバーレスポンス時間の短縮」監査（約600ミリ秒、サーバー時間のみ）か。これらは同じ数値ではありません。
• ラボだけでなくフィールドも確認する — PageSpeed Insights経由のCrUX、またはSearch ConsoleのCore Web Vitalsレポートから、75パーセンタイルでTTFBを取得します。
• TTFBがLCPを制限している要因かどうかを確認する — LCPが不良でページコンテンツが最適化されている場合、TTFBが最初の容疑者です。
• リダイレクトの数を数える — 主要なエントリURLで制御可能なリダイレクトチェーンを排除します。
• CDNがユーザーにサービスを提供していること（視聴者に近いエッジPoP）、およびHTML/エッジキャッシュが静的アセットだけでなく実際にヒットしていることを確認します。
• バックエンドをプロファイリングする — メインドキュメントリクエストでの遅いデータベースクエリや重いサーバーサイド処理。
• TLSが効率的であること（最新のプロトコル、セッション再開）とDNSが高速であることを確認します。
• ページが動的SSRの場合、フレームワークでストリーミングが有効になっているか確認します — 多くの場合、デフォルトでオフになっています。
• サーバー/CDNがサポートしている場合、レンダリングクリティカルなリソースに対して103 Early Hintsを検討します。
• サービスワーカーを使用している場合、その起動が初回読み込みのTTFBに追加されていないこと、およびキャッシュ戦略が再読み込みに役立つことを確認します。

TTFB早見表

TTFBが構成するもの

1. リダイレクト時間
2. サービスワーカーの起動（ある場合）
3. DNSルックアップ
4. 接続 + TLSネゴシエーション
5. リクエスト — レスポンスの最初のバイトまで

しきい値（実ユーザーロードの75パーセンタイル）

2つのしきい値、2つのスコープ

豆知識

• TTFBはCore Web Vitalsではありません。Core Web VitalsはLCP、INP、CLSです。
• これはフィールドとラボの両方の指標です。
• FCPとLCPの両方にTTFBが含まれます — TTFBはそれらに上限を設定します。
• ランキングへの影響はLCPを介して間接的です — TTFB自体はランキングシグナルではありません。
• DevToolsでは、ネットワークパネルで**「Waiting (TTFB)」**と表示されます。
• 「良好」のラインは2022年に500ミリ秒→800ミリ秒に移動しました。

修正の優先順位: ホスティング → CDN → HTML/エッジキャッシュ → リダイレクト削減 → マークアップのストリーミング → 103 Early Hints → 効率的なTLS → サービスワーカーの起動。

TTFB測定ツール

• PageSpeed Insights — 最も簡単なフィールド読み取り：URLまたはオリジンについて、ラボ実行と並べてCrUX TTFB（実際のChromeユーザー）を表示します。
• Search Console — Core Web Vitalsレポート — URLパターンごとにグループ化されたフィールドデータ；大規模なTTFB問題を発見する場所です。
• CrUX（Chrome User Experience Report）— 基盤となるフィールドデータセット；履歴トレンドについてはCrUX APIまたはBigQueryを介して直接クエリ可能です。
• Chrome DevTools — ネットワークパネル — メインドキュメントリクエストにカーソルを合わせて、接続とサーバー時間の正確なラボ内訳について**「Waiting (TTFB)」**タイミングを読み取ります。
• Lighthouse — **「サーバーレスポンス時間の短縮」**監査（約600ミリ秒のサーバー時間フラグ）を実行します；DevToolsとPageSpeed Insightsに組み込まれています。Lighthouse 13以降、このチェックは「ドキュメントリクエストの遅延」インサイト内に表示されます。
• WebPageTest — 接続フェーズごとにTTFBを分解した詳細なウォーターフォールと、地理的遅延を分離するための複数ロケーション/接続テスト。
• web-vitals JSライブラリ — フィールドで自分の実際のユーザーからTTFB（およびその他）を収集し、アナリティクスに送信します。

誤った修正につながるTTFBの間違い

すべての遅延をサーバーの問題と呼ぶ

TTFBには、リダイレクト、DNS、接続設定、TLS、サービスワーカーの起動、サーバー処理が含まれます。アプリケーションコードやホスティングを変更する前に、リクエストをフェーズに分割します。

Lighthouseの600ミリ秒監査と800ミリ秒のフィールドしきい値を比較する

Lighthouse 監査はより狭いラボ診断であり、0,8秒のガイドラインは完全な TTFB を説明しています。どちらの数値を報告する場合も、ソースとスコープを明記してください。

オリジン近くの場所からのみテストする

近くのラボでは地理的なレイテンシが隠れることがあります。同じエクスペリエンスが全ユーザーに適用されると想定する前に、リージョンを比較するか、実際のユーザーデータを使用してください。

ページがすでに高速なのに TTFB を追いかける

高い TTFB は、高速なストリーミングまたはキャッシュされたエクスペリエンスと両立する可能性があります。より大きなボトルネックよりも優先する前に、それが実際に FCP または LCP を制約しているかどうかを確認してください。

症状別に遅い TTFB を診断する

最初のリクエストは遅いが、繰り返しのリクエストは速い

考えられる原因: コールドキャッシュ、接続セットアップ、またはアプリケーションのウォームアップ。修正: キャッシュヘッダーを検査し、コールドテストとウォームテストを分離します。確認: ウォーターフォールは、繰り返しリクエストでどの接続またはサーバーフェーズが消えるかを示します。

TTFB が遠隔地でのみ遅い

考えられる原因: オリジンまでの物理的な距離または CDN キャッシュミス。修正: キャッシュ可能な HTML をユーザーの近くで配信し、エッジキャッシュの動作を検証します。確認: リージョナルテストで、レスポンスボディを変更せずに待ち時間が短縮されることを示します。

ある URL の TTFB がテンプレートの同等ページよりもはるかに悪い

考えられる原因: リダイレクト、キャッシュされていないルート、またはページ固有の高コストなバックエンド処理。修正: リダイレクトチェーン、キャッシュステータス、サーバータイミングを健全な同等ページと比較します。確認: 外れ値のドキュメントリクエストがテンプレートのベースラインに戻ることを示します。

DevTools と CrUX が一致しない

考えられる原因: 1 つのラボリクエストは、フィールドのデバイス、場所、キャッシュ状態、75 パーセンタイルを代表することはできません。修正: ラボリクエストを診断に使用し、フィールドデータを普及率の判断に使用します。確認: RUM の分布が、どのセグメントが遅い集計値を生み出しているかを説明していることを確認します。

コマンドラインから TTFB を測定する

curl のタイミング変数を使用して、最初のバイトを DNS、接続、TLS セットアップから分離します。

curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s starttransfer=%{time_starttransfer}s total=%{time_total}s\n' \
  https://example.com/

time_starttransfer はコマンドの TTFB スタイルの測定値です。複数の関連リージョンからコールドリクエストとウォームリクエストを数回実行します。単一のローカルサンプルはフィールドベンチマークではありません。

ブラウザで Navigation Timing を読む

const nav = performance.getEntriesByType('navigation')[0];
console.table({
  ttfb: Math.round(nav.responseStart - nav.requestStart),
  dns: Math.round(nav.domainLookupEnd - nav.domainLookupStart),
  connect: Math.round(nav.connectEnd - nav.connectStart),
});

TTFB の変更が有効になったことを証明する

エッジキャッシュテスト

実行するテスト: curl -sS -D - -o /dev/null で同じドキュメントを 2 回リクエストし、CDN のキャッシュステータスと age ヘッダーを検査します。期待される結果: 繰り返しリクエストは、CDN の文書化されたヘッダーに従ってキャッシュから配信されます。失敗の解釈: ルートがキャッシュをバイパスしているか、すぐに期限切れにしています。監視ウィンドウ: 即時。ロールバックトリガー: パーソナライズされた、認証された、または古い HTML が誤ったリクエストに配信されます。

リダイレクト削除テスト

実行するテスト: 最終的な公開 URL に curl -sS -I を使用し、リダイレクトチェーンを個別に検査します。期待される結果: 意図したエントリ URL が、回避可能なホップなしでドキュメントに到達します。失敗の解釈: ルーティングまたは正規ホストルールが依然としてラウンドトリップを追加しています。監視ウィンドウ: 即時。ロールバックトリガー: 変更により、必要な HTTP から HTTPS へのリダイレクトまたはホスト名の正規化が壊れます。

フィールド TTFB テスト

実行するテスト: リリース後の Navigation Timing または web-vitals TTFB をリージョンとテンプレートごとにリリース前のベースラインと比較します。期待される結果: 影響を受けるセグメントで p75 がエラーなしで改善されます。失敗の解釈: ラボでの改善が実際のユーザーに届かなかったか、作業を他の場所に移しました。監視ウィンドウ: RUM トラフィックが到着するにつれて。CrUX はローリングウィンドウ上で。ロールバックトリガー: エラーレート、キャッシュの正確性、またはユーザーに表示されるレイテンシが悪化します。

追跡する価値のある TTFB メトリクス

p75 での実際のユーザー TTFB

指標: テンプレート、地域、デバイスクラス別の75パーセンタイルTTFB。それが示すもの: レンダリングを開始する前に、ドキュメントリクエストが実際の訪問の大半をどれだけ遅延させるか。取得方法: Navigation Timing、web-vitalsライブラリ、CrUX、またはPageSpeed Insights。ベンチマーク/現実的な範囲: 0,8秒以下がこの記事で説明されている良い目標です。セグメントごとに解釈してください。頻度: RUMでは毎週、公開フィールドのトレンドは毎月。

キャッシュヒットTTFBとキャッシュミスTTFB

指標: CDNのキャッシュ結果別のp75 TTFB。それが示すもの: 遅延の原因がオリジン側の処理なのか、エッジ配信なのか。取得方法: レスポンスのキャッシュステータスヘッダーをRUMまたはCDNログと結合します。ベンチマーク/現実的な範囲: プロバイダー、ルート、パーソナライゼーションが異なるため、サイト独自の地域ベースラインを使用します。頻度: 毎週、およびキャッシュルール変更後。

LCPに占めるTTFBの割合

指標: 同じ訪問のLCP時間に対するTTFBの割合。それが示すもの: サーバーと接続時間が読み込み体験の制限要因になっているかどうか。取得方法: RUMでTTFBとLCPを一緒に収集します。ベンチマーク/現実的な範囲: 普遍的なパーセンテージは正直ではありません。TTFBがLCPの大部分を一貫して占める場合は、TTFBを優先します。頻度: テンプレートごとに毎月。

時間をかける価値のあるリソース

関連記事

• Core Web Vitals: 初心者向けガイド — 読み込み指標の中でTTFBがどこに位置するか、そしてなぜ補助的な指標でありランキングシグナルではないのか。
• 技術的SEOの初心者向けガイド — サイトパフォーマンスが位置するより大きな全体像。

公式

• web.devのTTFBとTTFBの最適化 — 決定的な2つのページ。
• Chromeチームの103 Early Hintsに関する記事。Shopify/Cloudflareの結果付き。

データ

• HTTP Archive Web Almanac — パフォーマンスの章 — ウェブ全体の長期的なTTFBとLCPのフィールドデータ。

業界からの情報

• Cloudflareブログ: Early Hints — 103 Early Hintsの提供に関するCloudflare自身の記事。実際の結果とCDN実装の詳細を含む。
• web-vitals JSライブラリ (GitHub) — 実際のユーザーからTTFB（およびすべてのWeb Vitals）を収集するための標準ライブラリ。これを使用してフィールドTTFBを独自の分析ツールに送信します。
• HTTP Archive Web Almanac 2022 — パフォーマンス — 当時の新しい800msのしきい値の下でモバイルのgood-TTFBが40%だったことを示す過去のベースライン。複数年にわたるトレンドの文脈に役立ちます。
• Fastly — HTTP/2 Server Push vs Early Hints — TTFBへの影響を減らすためにEarly HintsがServer Pushに取って代わりつつある理由についてのCDNの視点。

引用に値する統計

• モバイルサイトの約42%が「良好」なTTFBを達成 — 5年間でほとんど変化なし。 Web Almanacのモバイルの良好TTFB率は、5年間のデータで約41〜42%で推移しています： 根強い、ウェブ全体の停滞です。 出典
• LCPが不良のサイトでは、TTFBだけで約2,27秒を消費 — コンテンツがレンダリングされる前に、 「良好なLCP」の閾値である2,5秒のほぼ全体を占めています。TTFBは、LCPを失敗するサイトにとって最大のサブパートです。 出典
• 103 Early Hintsは、ShopifyとCloudflareのテストで数百ミリ秒のLCP改善をもたらしました — 場合によっては1秒近く速くなりました。 出典
• 「良好」なTTFBの基準線は2022年に500 msから800 msに変更され、過去のデータは新しい基準で再計算されました — 古いTTFBの数値を比較する前に知っておく価値があります。 出典

自分で試す：Time to First Byte

TTFBが測定するものと、それを改善する方法に関する5つの簡単な質問です。各質問に回答を選び、確認してください。

変更履歴