Time to First Byte（TTFB）とは何か、どう改善するか

Time to First Byte（TTFB）は、ブラウザがページをリクエストしてから、サーバーからのレスポンスの最初の1バイトを受信するまでの時間をミリ秒単位で計測する指標です。75パーセンタイルで800ミリ秒以下であれば良好と評価されます。TTFBはCore Web Vitalsではありませんが、Largest Contentful Paint (LCP)とFirst Contentful Paint (FCP)の両方に直接影響するため、極めて重要な診断指標です。

Time to First Byteとは

Time to First Byte（TTFB）は、リクエストの開始からWebページからの最初のレスポンス（バイト）を受信するまでの経過時間をミリ秒単位で表したものです。そのため、TTFBは「待機時間（waiting time）」とも呼ばれます。TTFBは、Webサーバーの応答性と、ユーザーとそのサーバー間のネットワーク経路を計測するための指標です。TTFBは基礎となる指標であり、TTFBに加算された時間はそのままLargest Contentful PaintとFirst Contentful Paintにも加算されます。TTFBを1ミリ秒短縮できれば、これら2つの描画指標もそのまま1ミリ秒短縮できます。

TTFBはCore Web Vitalsではありません

まず明確にしておくべき点があります。TTFBは3つのCore Web Vitalsには含まれません。Core Web Vitalsを構成するのは、Largest Contentful Paint (LCP)、Interaction to Next Paint (INP)、Cumulative Layout Shift (CLS)の3つです。Googleはページ体験のランキングシグナルにおいてTTFBを直接使用していません。

ただし、TTFBは診断指標に分類されます。LCPやFCPが遅くなっている原因を突き止めるのに役立ちます。2025 Web Almanacによると、LCPが不良なサイトではTTFBだけで平均2.27秒を費やしており、ブラウザがページの描画を開始する前に2.5秒というLCPの基準値をほぼ使い果たしています。したがって、TTFBの改善は、Core Web Vitals全体のスコアを引き上げるうえで最も効果的な施策の1つです。

Time to First Byteが重要な理由

Time to First ByteはCore Web Vitalsではありません。TTFBの評価が悪くても、Core Web Vitalsに合格することは十分に可能です。しかし、だからといってTTFBが重要でないわけではありません。TTFBは最適化すべき極めて重要な指標であり、TTFBを改善すればページ速度とページ体験は大きく向上します。

訪問者に対するTTFBの影響

Time to First Byteは、他のあらゆる描画指標に先立って発生します。ブラウザはTime to First Byteの完了を待つ間、何も処理できず、ただ白画面を表示し続けます。つまり、Time to First Byteが増加すれば「白画面」の時間が増え、Time to First Byteを短縮できれば「白画面」の時間を減らすことができます。

ページが瞬時に読み込まれる体感を得るには、Time to First Byteをできる限り高速にする必要があります。

なぜTTFBはCore Web Vitalsではないのか？ TTFBはレンダリングを考慮していません。ブラウザがWebページを描画するまでの時間を考慮しないため、TTFBが速いからといって必ずしも優れたユーザー体験を意味するわけではありません。すべてのバイトが高速にダウンロードされたとしても、ブラウザが大量のJavaScriptを処理したり複雑なレイアウトを描画したりする必要があれば、ページの表示には依然として長い時間がかかる可能性があります。

良好なTTFBスコアの基準

75パーセンタイルのユーザーが「良好」のしきい値内でFCPを体験できるよう、サーバーはナビゲーションリクエストに十分な速度で応答することが推奨されます。大まかな目安として、大半のサイトでは0.8秒以下のTTFBを目指すべきです。

• 800ミリ秒未満のTTFBは良好とみなされます。
• 800〜1800ミリ秒のTTFBは改善が必要です。
• 1800ミリ秒超のTTFBは不良とみなされ、早急な改善が必要です。

実際の導入効果：T-Mobileの事例

T-Mobileは、包括的なパフォーマンス最適化の取り組みの一環として、Time to First Byteの短縮に多額の投資を行いました。その成果は目覚ましく、訪問から注文へのコンバージョン率が60%増加しました。エッジレンダリングへの移行と積極的なサーバーサイドキャッシュの導入により、最初の1バイトを待つ時間を大幅に短縮し、それがLCPやFCPの高速化、そして目に見えるユーザー体験の向上へと連鎖しました。この事例は、TTFBの最適化が単なる技術的な作業にとどまらず、ビジネスの成果に直結することを証明しています。

リクエストからレスポンスまでのTTFB

ブラウザからサーバーへ：リクエスト

ブラウザのリクエスト時間とは、ユーザーのブラウザがHTTPリクエストを送信してから、Webサイトをホストするサーバーにそのリクエストが到達するまでの経過時間です。この区間のTTFBはWebサイト側で直接コントロールすることが難しく、主に以下の要因に左右されます。

• ユーザーのインターネット回線速度
• 利用しているネットワークインフラの品質
• ユーザーとサーバー間の物理的な距離

この段階では、DNSルックアップ、ブラウザの起動時間、ブラウザのキャッシュ確認、そしてサーバーへの接続ネゴシエーション（TCPおよびTLS）のすべてに一定の時間を要します。

サーバー側：レスポンスの処理と準備

サーバーがリクエストを受信すると、レスポンスの生成に向けて処理が進みます。多くの開発者が注力しがちなのがこのフェーズであり、最適化の取り組みが最も顕著な効果を発揮する場所でもあります。考慮すべき要因は以下のとおりです。

• サーバーのスペック：強力なハードウェア（CPU、RAM）、効率的なソフトウェア（Webサーバー、データベース）、そして最適化された設定のすべてが重要です。
• データベース処理時間：リクエストでデータベースからのデータ取得が必要な場合、低速なクエリが主要なボトルネックになり得ます。
• コードの最適化：非効率なスクリプトなど、適切に書かれていないサーバーサイドコードは処理時間の長期化を招きます。
• キャッシュ戦略：サーバーサイドキャッシュやCDNの活用など、効果的なキャッシュ戦略により、再リクエスト時の処理負荷を劇的に削減できます。

ブラウザへの返送：最初の1バイトの配信

処理完了後、サーバーは最初の1バイトを皮切りに、レスポンスをユーザーのブラウザへ返送します。

• 第1段階と同様に、ここでもネットワーク環境や距離が影響します。
• この段階ではCDNが極めて有効です。コンテンツをユーザーの近くにキャッシュすることで、転送時間を最小限に抑えられます。
• リダイレクトはこの時点で返されるため、一連のプロセスが最初からやり直しになり、余計な遅延が発生します。

Time to First Byteの技術的な内訳

ブラウザにおける「リクエストからレスポンスまでの経路」と同様に、ナビゲーションリクエストのTime to First ByteはNavigation Timing APIで計測でき、5つの構成要素に分解できます。

1. リダイレクト時間：リソースが新しい場所に移動されている場合、そのリダイレクトにかかる時間がリソースのTTFBに加算されます。
2. Workerとキャッシュの処理時間：リソースをインターネット経由で取得する前に、ブラウザはまず自身のキャッシュ内を検索するか、Worker（設定されている場合）経由で取得を試みます。
3. DNSルックアップ時間：次に、ドメイン名（www.example.com）をIPアドレスに変換するため、ブラウザはDNSルックアップを実行する必要があります。
4. TCP接続時間：続いて、ブラウザがサーバーに接続し、接続確立のための確認処理を行います。
5. SSLハンドシェイク：その後、ブラウザとサーバー間で通信を暗号化します。
6. サーバーレスポンス：最後に、サーバーがHTMLを送信します。その前にHTMLの生成が必要になる場合もあります。

Time to First Byte（TTFB）の計測方法

PageSpeed TIP：すべてのリソースにそれぞれのTime to First Byteが存在します。ただし、ここでの文脈ではメインページのTime to First Byteを指しています。

Time to First Byteは、ユーザーの端末やアクセス元の地域によって大きく変動します 。そのため、手元のデスクトップPCから自分でTime to First Byteを計測するのは賢明な方法とは言えません。同様の理由から、PingdomやGTmetrixのようなツールによる計測も信頼性に欠けます。

Time to First Byteを計測する最善の方法は、実際の訪問者からRUM（Real User Metrics）データを収集することです。後述のコードを使って独自に実装することも、CoreDashのようなRUMツールを利用することもできます。

シンセティック計測ツールでTTFBを計測する

RUMトラッキングでTTFBを計測する

CrUXデータでTTFBを計測する

CrUX（Chrome User Experience Report）は、Webサイトの実際のパフォーマンスデータを収録したGoogleの公開データセットです。GoogleはCore Web Vitalsの合否判定にCrUXデータセットを使用しています。

CrUXデータセットには、PageSpeed Insights、CrUX API、Looker Studio、Google BigQueryなどのツールからアクセスできます。これらのツールのいずれかを使用して、サイトのTTFBを取得してください。

JavaScriptでTTFBを計測する

JavaScriptでTime to First Byte（TTFB）を計測するには、Navigation Timing APIを使用します。PerformanceObserverを作成してナビゲーションエントリを監視し、responseStartプロパティをコンソールに出力します。responseStartプロパティは、レスポンスの最初の1バイトを受信したタイムスタンプを表します。また、web-vitals JavaScriptライブラリのonTTFB関数を使用すれば、ブラウザ上でより簡潔にTTFBを計測できます。

以下のコードを使用して、Time to First Byte（TTFB）を計測できます。

const formatTime = (time) => {

//round by 2 decimals, use Math.round() for integer
return Math.round(time * 100) / 100;
};

new PerformanceObserver((entryList) => {
const [pageNav] = entryList.getEntriesByType('navigation');

// timing start times are relative
const activationStart = pageNav.activationStart || 0;
const workerStart = Math.max(pageNav.workerStart - activationStart, activationStart);
const dnsStart = Math.max(pageNav.domainLookupStart - activationStart, workerStart);
const tcpStart = Math.max(pageNav.connectStart - activationStart, dnsStart);
const sslStart = Math.max(pageNav.secureConnectionStart - activationStart, tcpStart);
const requestStart = Math.max(pageNav.requestStart - activationStart, sslStart);
const responseStart = Math.max(pageNav.responseStart - activationStart, requestStart);

// attribution based on https://www.w3.org/TR/navigation-timing-2/#processing-model
// use associative array to log the results more readable
let attributionArray = [];
attributionArray['Redirect Time'] = { 'time in ms': formatTime(workerStart - activationStart) };
attributionArray['Worker and Cache Time'] = { 'time in ms': formatTime(dnsStart - workerStart) };
attributionArray['DNS Time'] = { 'time in ms': formatTime(tcpStart - dnsStart) };
attributionArray['TCP Time'] = { 'time in ms': formatTime(sslStart - tcpStart) };
attributionArray['SSL Time'] = { 'time in ms': formatTime(requestStart - sslStart) };
attributionArray['Request Time'] = { 'time in ms': formatTime(responseStart - requestStart) };
attributionArray['Total TTFB'] = { 'time in ms': formatTime(responseStart - activationStart) };

// log the results
console.log('%cTime to First Byte (' + formatTime(responseStart - activationStart) + 'ms)', 'color: blue; font-weight: bold;');
console.table(attributionArray);

console.log('%cOrigininal navigation entry', 'color: blue; font-weight: bold;');
console.log(pageNav);

}).observe({
type: 'navigation',
buffered: true
});

Server-Timing APIでボトルネックを特定する

Server-Timing APIは、バックエンドサーバーの処理時間をブラウザへ渡すための標準化された仕組みです。Server-Timingヘッダーを活用することで、TTFBを構成するサーバーサイドの各要素を正確に計測・分析できます。これにより最適化すべき箇所を特定し、Webサイト全体のパフォーマンス改善につなげることが可能です。

Server-Timingヘッダーには、カンマ区切りで複数の指標の所要時間を含めることができます。各エントリは以下の要素で構成されます。

• 指標の短い名前（databaseやprocessingなど）
• ミリ秒単位の所要時間（dur=123の形式）
• 任意の説明（desc="My Description"の形式）

Server-Timing: database;dur=123;desc="DB Query", processing;dur=234;desc="Template Render", cache;dur=0;desc="Cache HIT"

Chrome DevToolsでServer-Timingを確認する

Chrome DevToolsは、NetworkパネルにServer-Timingのエントリを直接表示します。DevToolsを開き、Networkタブでドキュメントのリクエストを選択して、Timingタブの「Server Timing」セクションまでスクロールしてください。Server-Timingヘッダー経由で送信した各指標が、名前、説明、所要時間とともに出力されます。これにより、データベース、テンプレートのレンダリング、キャッシュ層のどこがボトルネックになっているかを簡単に特定できます。

また、Server-Timingヘッダーをプログラムから読み取り、CoreDashなどのRUMツールに送信して、長期的な追跡やアラート通知に役立てることも可能です。

103 Early HintsでTTFBを高速化する

103 Early Hintsは、最終的なレスポンスの準備が整う前に、サーバーから予備的なレスポンスヘッダーをブラウザへ送信できるHTTPステータスコードです。サーバーがリクエストを処理中（データベースへのクエリ発行やテンプレートのレンダリング中）であっても、ブラウザ側ではスタイルシート、フォント、LCP画像といった重要リソースの読み込みを先行して開始できます。

103 Early Hintsの仕組み

従来のリクエストフローでは、サーバーの処理が終わるまでブラウザは何もできずに待機していました。103 Early Hintsを使用すると、サーバーはリクエスト受信直後に部分的なレスポンスを返します。このレスポンスには、プリロードまたは事前接続（preconnect）すべきリソースをブラウザに指示するLinkヘッダーが含まれています。ブラウザは完全な200レスポンスを待つ間、これらのヒントに基づいて処理を進めます。

これにより、無駄な待機時間を有益な読み込み時間へと変えられます。103 Early Hintsはドキュメント自体のTTFBを短縮するわけではありませんが、ブラウザにリソースの発見を先回りさせることで、LCPやFCPといった後続の指標に対するTTFBの体感的な影響を低減できます。

103 Early Hintsのサーバー設定例

現在では多くのCDNやWebサーバーが103 Early Hintsをサポートしています。以下はCloudflareの設定例です。HTML内のLinkヘッダーやpreload/preconnectタグから103 Early Hintsを自動生成します。

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </static/img/hero.webp>; rel=preload; as=image
Link: <https://fonts.googleapis.com>; rel=preconnect

HTTP/1.1 200 OK
Content-Type: text/html
...

Nginxの場合、レスポンスにLinkヘッダーを追加し、HTTP/2またはHTTP/3プッシュを有効にすることでEarly Hintsを設定できます。ApacheではH2EarlyHintsディレクティブで103 Early Hintsをサポートしています。詳しい手順については、103 Early Hintsの実装に関する詳細ガイドを参照してください。

Speculation Rules APIでTTFBをゼロにする

Speculation Rules APIは、次回以降のナビゲーションのパフォーマンスを向上させるために設計されています。訪問者がページにアクセスした段階で、Speculation Rulesを使って、次にアクセスする可能性が高いページをブラウザにあらかじめ取得（prefetchディレクティブ）させたり、完全に描画（prerenderディレクティブ）させたりできます。

Speculation RulesがTTFBをゼロにする仕組み

ページが事前レンダリング（prerender）されると、ブラウザは非表示のタブでそのページを完全に読み込み、レンダリングまで完了させます。ユーザーがリンクをクリックすると、事前レンダリング済みのページが瞬時に切り替わって表示されます。その結果、計測されるTTFBは0ミリ秒になります。これは理論上の数字ではありません。corewebvitals.ioのCoreDash RUMデータでも、Speculation Rulesによる事前レンダリングナビゲーションのp75 TTFBが0msであることが確認されています。

プリフェッチ（prefetch）は、より軽量な代替手段です。ページを完全にレンダリングするのではなく、HTMLドキュメントのみを取得してキャッシュします。ナビゲーション時にブラウザがドキュメントを解析して描画する処理は残るものの、TTFBのネットワーク遅延部分は排除できます。

Speculation RulesのJSON構文

Speculation Rulesは、JSONを記述した<script type="speculationrules">ブロックで定義します。以下は、メニューバー内のすべてのナビゲーションリンクを「moderate」（ホバーまたはポインターダウンをトリガーとする設定）で事前レンダリングする例です。

<script type="speculationrules">
{"prerender":
[{
  "source": "document",
  "where": {"selector_matches": "nav a"},
  "eagerness": "moderate"
}]}
</script>

特定のURLを指定するリスト形式のアプローチも利用できます。

<script type="speculationrules">
{"prefetch":
[{
  "source": "list",
  "urls": ["/core-web-vitals/", "/pagespeed/103-early-hints"]
}]}
</script>

Speculation Rulesのブラウザ対応は拡大しています。Chrome 121以降では、ドキュメントルールを含むAPI全体がサポートされています。Speculation Rulesにまだ対応していないブラウザ向けには、代替手段としてquicklinkのような軽量スクリプトをfallbackとして活用できます。サイトに合わせた最適な設定を作成するには、Speculation Rulesジェネレーターをご利用ください。

ホスティング環境はTTFBにどう影響するか

ホスティング環境はさまざまな形でTime to First Byteに影響します。より優れたホスティングに投資することで、他の部分に手を加えることなく、即座にTime to First Byteを改善できるのが一般的です。とりわけ、格安の共有レンタルサーバーから適切に設定・管理された仮想サーバーへ移行した場合、TTFBは劇的に改善する可能性があります。

Hosting TIP：優れたホスティング環境とは、高速な処理能力、高速なネットワーク、そして大容量かつ高速なサーバーメモリを備えているものを指します。高額なホスティングが必ずしも優れたホスティングとは限りません。共有ホスティングのプランをアップグレードしても、増えるのはストレージ容量だけでCPU性能は変わらないケースが多々あります。

TTFBの問題の根本原因を把握しないままホスティングを乗り換えることはおすすめしません。まずはRUMトラッキングを設定し、Server-Timingヘッダーを追加してください。

ホスティングをアップグレードする際は、基本的に以下の3つの改善点のうち少なくとも1つを期待できるか確認してください。

• リソースの増強（CPU + RAM）：サーバーが動的HTMLの生成に時間を要している場合に特に効果的です。
• 高速なDNS：格安のホスティング事業者の多くは、DNSの応答性能が劣悪なことで知られています。
• より優れたサーバー設定：高速なSSL暗号スイート、HTTP/3、Brotli圧縮、不要なモジュールを無効化できるWebサーバー設定へのアクセス権などが挙げられます。

TTFBの改善方法：初期接続を高速化する

Time to First Byteが遅くなる原因は複数あります。しかし、DNS、TCP、SSLはあらゆるリクエストのTime to First Byteに影響します。まずはここから着手しましょう。この3つの最適化による短縮幅は最大ではないかもしれませんが、すべてのTTFBを一律で底上げできます。

DNSを高速化する

PageSpeed TIP：格安ホスティングを利用している場合や、CDNを使わずに世界中のユーザーに配信している場合、DNS、TCP、SSLがより深刻なボトルネックになりがちです。RUMトラッキングを活用して全世界のTTFBを確認し、内訳の各要素を分析してください。

高速なDNSプロバイダを利用してください。すべてのDNSプロバイダが同じ速度で動作するわけではありません。（無料の）DNSプロバイダ間でも明確な速度差があります。たとえばCloudflareなら、世界最速クラスのDNSを無料で利用できます。

DNSのTTLを長く設定する：もう1つの方法は、Time to Live（TTL）の値を増やすことです。TTLはルックアップ結果をキャッシュする期間を指定する設定です。TTLを長く設定するほど、ブラウザが再度DNSルックアップを実行する頻度を減らせます。なお、ISP側でもDNSがキャッシュされる点に留意してください。

TCPを高速化する

TTFBにおける「TCP」の部分は、Webサーバーとの初期接続を指します。接続時、ブラウザとサーバーはデータのやり取り方法に関する情報を共有します。TCPを高速化するには、地理的に近い場所にあるサーバーへ接続すること、そしてサーバーの空きリソースを十分に確保することが重要です。場合によっては、NGINXのような軽量なWebサーバーに切り替えることでTCP接続を高速化できます。多くの場合、CDNの導入がTCP接続の高速化に直結します。

SSL/TLSを高速化する

TCP接続が確立されると、ブラウザとサーバーは暗号化によって接続を保護します。これを高速化するには、より新しく軽量で高速なプロトコル（SSL暗号スイート）を採用し、Webサーバーとの物理的な距離を近づけることが有効です（TLSネゴシエーションには往復の通信が複数回発生するためです）。CDNは適切にチューニングされており世界各地にエッジサーバーを展開しているため、CDNの利用がSSL接続時間の改善につながるケースが多々あります。特にTLS 1.3は、ネゴシエーションの所要時間を極力短縮するように設計されています。

TTFBの改善方法：サーバーサイドを高速化する

ページキャッシュ

Time to First Byteを高速化するうえで、サーバーキャッシュからHTMLを配信することが最も効果的です。フルページキャッシュを実装する方法はいくつかあります。最も有効なのは、NGINXのキャッシュモジュールを利用したり、リバースキャッシュプロキシとしてVarnishを導入したりするなど、Webサーバー層で直接処理することです。

各種CMS向けにもページ全体をキャッシュするプラグインが多数存在します。また、Next.jsなどの多くのSPAフレームワークも、キャッシュ破棄戦略を備えた独自のフルページキャッシュ機能を実装しています。

独自にキャッシュを実装する場合、基本的な考え方はシンプルです。クライアントからページのリクエストがあった際、キャッシュフォルダ内に該当ファイルが存在するかを確認します。存在しない場合はページを生成してキャッシュに保存し、通常通り表示します。次回以降のリクエストではキャッシュファイルが存在するため、キャッシュから直接ページを配信できます。

部分キャッシュ

部分キャッシュでは、頻繁に使用されるパーツや、処理の重い要素（API呼び出し、データベースの取得結果など）をキャッシュして高速に取り出せるようにします。これにより、ページ生成時のボトルネックを解消できます。この種の最適化に関心がある場合は、メモリキャッシュ、オブジェクトキャッシュ、データベースキャッシュ、ORM（Object-Relational Mapping）キャッシュ、コンテンツフラグメントキャッシュ、Opcodeキャッシュといった概念を調べてみてください。

アプリケーションコードの最適化

キャッシュファイルが存在しない場合や、ページの大半が動的である場合、あるいはその他の問題により、（部分）キャッシュから配信できないこともあります。そのため、アプリケーションコード自体の最適化が不可欠です。具体的な実装手法はアプリケーションによって異なりますが、処理の遅いコード箇所を書き直し、効率化することが基本となります。

データベースクエリの最適化

多くの場合、非効率なデータベースクエリがTime to First Byteの遅延の根本原因です。まずは「スロークエリ」や「インデックスを使用していないクエリ」をログに出力することから始めてください。それらを分析し、インデックスを追加するか、専門家に依頼してデータベースチューニングを行って問題を解消しましょう。詳細はMongoDB Performance AdvisorやMySQL Slow Query Logを参照してください。

内部ネットワークの遅延を削減する

現場で思っている以上によく目にする悪習が、Webアプリケーションとデータストレージ間の通信遅延によるTime to First Byteの悪化です。これは通常、データストレージをクラウドAPIに委託している大規模サイトで発生します。

TTFBの改善方法：クライアントサイドを高速化する

クライアントサイドキャッシュ

クライアントサイドキャッシュとは、画像やスクリプトなど、一度アクセスしたリソースをユーザーのブラウザ側に保存する仕組みです。ユーザーがサイトを再訪問した際、ブラウザはそれらを再ダウンロードすることなくキャッシュから即座に取得できます。これによりサーバーへのリクエスト数を大幅に削減でき、結果としてTTFBの改善につながります。

クライアントサイドキャッシュを実装するには、HTTPのCache-Controlヘッダーを使用します。このヘッダーにより、特定のリソースをブラウザがキャッシュする期間を指定できます。

ページのHTML自体をクライアント側で完全にキャッシュすることも検討できます。サーバーへのリクエストが一切発生しないため、TTFBは劇的に短縮されます。ただし、一度ブラウザのキャッシュに入ると、キャッシュの有効期限が切れるまで本番環境の更新内容がユーザーに反映されないというデメリットがあります。

Service Workers

Service Workerは、ブラウザのバックグラウンドで動作し、ブラウザからのネットワークリクエストをインターセプトできるスクリプトです。HTML、画像、スクリプト、スタイルシートなどのリソースをService Workerでキャッシュしておくことで、再訪問時にそれらを再ダウンロードせず即座に取得できるようになります。

ページのプリフェッチ

まだブラウザのサポートが限られているという理由でSpeculation Rules APIの採用を見送る場合は、quicklinkという軽量スクリプトの利用を検討してください。表示領域（viewport）内にあるすべてのリンクをプリフェッチし、それらのリンクに対するTime to First Byteをほぼゼロにできます。

quicklinkの欠点はブラウザのリソース消費が増えることですが、現時点でのブラウザの対応範囲という点ではSpeculation Rules APIよりも優れています。

TTFBの改善方法：CDNを活用する

CDN（Content Delivery Network）は、分散されたサーバーネットワークを利用してリソースをユーザーに配信します。これらのサーバーは通常、エンドユーザーの地理的に近い場所に配置され、配信速度が高度に最適化されています。Cloudflareをご利用の場合は、Core Web Vitalsを最適化するためのCloudflare設定ガイドをご確認ください。

CDNとエッジキャッシュ適用時のTTFB

CDN非適用時のTTFB（ドイツでホスト）

CDNは、Time to First Byteを構成する6要素のうち5つを改善するのに役立ちます。

• リダイレクト時間：大半のCDNはリダイレクトをエッジでキャッシュできるほか、エッジワーカーを使用してオリジンサーバーに接続することなくリダイレクトを処理できます。
• DNSルックアップ時間：大半のCDNは極めて高速なDNSサーバーを提供しており、現在お使いのDNSサーバーよりも優れたパフォーマンスを発揮するはずです。
• TCP接続およびSSLハンドシェイク時間：大半のCDNは設定が高度に最適化されており、エンドユーザーとの物理的な距離の近さも相まって、接続やハンドシェイクの時間を短縮できます。
• サーバーレスポンス：CDNは複数のアプローチでサーバー応答時間を高速化します。エッジでサーバーレスポンスをキャッシュする（フルページエッジキャッシュ）だけでなく、優れた圧縮（Brotli）や最新のプロトコル（HTTP/3）も提供します。

TTFBの改善方法：リダイレクトを回避する

リダイレクトにかかる時間はそのままTime to First Byteに加算されます。したがって、原則としてリダイレクトは極力避けてください。リダイレクトは、リソースが以前の場所から別の場所へ移動した際に発生します。サーバーがリダイレクトのレスポンスヘッダーを返し、ブラウザはその新しいURLへ改めてアクセスを試みます。

同一オリジンのリダイレクト：同一オリジンのリダイレクトは、自社サイト内のリンクから発生します。これらは完全に自身で管理できるリンクであるため、Time to First Byteを改善する際は最優先で修正すべきです。Webサイト全体のリダイレクトを検出できるツールは数多く存在します。

クロスオリジンのリダイレクト：外部サイトのリンクから発生するリダイレクトです。こちら側でコントロールすることはほぼ不可能です。

多重リダイレクト：1回のリダイレクトでリソースの最終的なURLに到達せず、リダイレクトが連鎖（リダイレクトチェーン）する現象です。この手のリダイレクトはTime to First Byteを著しく悪化させるため、絶対に避けるべきです。これもツールを使って検出し、速やかに修正してください。

HTTPからHTTPSへのリダイレクト：これを回避する有効な手段がStrict-Transport-Securityヘッダー（HSTS）の導入です。初回訪問時にHTTPS接続を強制し、次回以降のアクセスでは最初からHTTPSスキームで接続するようブラウザに指示します。

ユーザーがWebページをリクエストした際、サーバーが別のページへのリダイレクトを返すことがあります。このリダイレクトが発生すると、ブラウザは遷移先のページに対して追加のリクエストを発行しなければならないため、TTFBに余分な時間が上乗せされます。

リダイレクトを回避する、あるいはその影響を最小限に抑える方法はいくつかあります。

1. 内部リンクを更新する：ページのURLを変更した際は、以前のURLへのリンクが残らないよう、そのページへ向けられた内部リンクをすべて更新してください。
2. リダイレクトはサーバーレベルで処理する。
3. 相対URLを使用する：自社サイト内のページにリンクする際は、絶対URLではなく相対URLを使用します。これにより、不要なリダイレクトを防ぐことができます。
4. canonical URLを使用する：類似したコンテンツを持つページが複数存在する場合は、正規URL（canonical URL）を指定して優先すべきページを明示します。重複コンテンツや不要なリダイレクトの防止に有効です。
5. 301リダイレクトを使用する：リダイレクトが避けられない場合は、302ではなく301リダイレクトを使用してください。301は恒久的な転送、302は一時的な転送を意味します。301リダイレクトを使用することで、不要な再リダイレクトの発生を抑制できます。

TTFBとあわせてリソースの優先順位付けを最適化する

TTFBの短縮は、読み込みパフォーマンス改善の第一歩にすぎません。最初の1バイトが到達した後、ブラウザはどのリソースを優先して処理すべきかを把握する必要があります。最速のページ読み込みを実現するために、fetchpriority、preload、preconnectといったヒントが高速なTTFBとどう連携するかについては、リソースの優先順位付けガイドをご覧ください。また、サードパーティへのDNSルックアップや接続時間を排除し、体感的なTTFBを短縮するために、Google Fontsのセルフホストも検討してください。

実測データが示すTTFBの実態

以下のデータは、CoreDashのRUM（Real User Monitoring）および2025 Web Almanacの調査結果に基づいています。

地域による格差は極めて大きい

TTFBは、ユーザーとサーバー間の物理的な距離によって劇的に変化します。corewebvitals.io（欧州でホスト）のCoreDashデータを見ると、その差は一目瞭然です。

サーバーに近い欧州のユーザーは170ms未満のTTFBを記録しているのに対し、インドのユーザーは3倍、中国のユーザーは万里のファイアウォール（Great Firewall）と長大な物理的距離の影響で10倍近いTTFB（1,468ms）となっています。このデータは、グローバルなオーディエンスを抱えるサイトにとって、世界各地にエッジ拠点を備えたCDNがいかに不可欠であるかを如実に物語っています。

Speculation RulesのprerenderならTTFBを0msにできる

CoreDashのナビゲーション種別データによると、Speculation Rulesで事前レンダリングされたページのp75 TTFBは0ミリ秒を達成しています。通常のナビゲーションでは131ms、再読み込み（リロード）はウォーム接続の恩恵を受けて82ms、戻る・進む（back-forward）ナビゲーションが最も遅く244msでした。この結果から、Speculation Rulesが次回以降のページ読み込みにおいてTTFBを解消する最も効果的な手法であることがわかります。

モバイルのTTFBはデスクトップの2.5倍

corewebvitals.ioでは、デスクトップのp75 TTFBが124msであるのに対し、モバイルユーザーは316msを要しています。この2.5倍の差はサーバーの性能差ではなく、モバイル回線の遅延によるものです。デスクトップでは96.1%のページ読み込みが「良好」なTTFB評価を達成しているのに対し、モバイルでは88.5%にとどまります。TTFBを最適化する際は、必ず実機のモバイル回線でテストしてください。

新規訪問者とリピーターのTTFBはほぼ同等

当サイトでは、新規訪問者のp75 TTFBが127ms、リピーターが138msとなっています。この差の小ささは、TTFBのパフォーマンスを決定づけているのが（クライアント側のキャッシュ効果ではなく）安定したサーバーサイドキャッシュであることを示唆しています。サーバーサイドキャッシュを導入していないサイトでは、新規訪問者とリピーターの間でさらに大きな差が生じます。

全世界のTTFBはこの5年間停滞している

2025 Web Almanacによると、全世界のモバイルページで「良好」なTTFBスコアを達成しているのはわずか44%にすぎません。この数値は2021年の41%からほとんど変化しておらず、Web上で最も改善が進んでいないパフォーマンス指標となっています。同じ期間にLCPが44%から59%へ、INPが55%から74%へと改善したのとは対照的です。LCPが不良なサイトでは、TTFBだけで平均2.27秒を費やしており、LCPの許容基準である2.5秒をほぼ使い切っています。

関連ガイド：TTFBの内訳要素

Time to First Byteを構成する各要素には、それぞれ固有の最適化アプローチが存在します。

• <b>TTFB問題の特定と改善</b>：DevTools、Server-Timing、RUMデータを活用し、低速なTTFBの根本原因を特定するための段階的な診断ガイド。
• <b>待機時間の短縮</b>：TTFBを増大させるリダイレクト時間やサーバー処理遅延を最小限に抑える方法。
• <b>キャッシュ処理時間の短縮</b>：ブラウザキャッシュ、Service Worker、bfcache（Back/Forward Cache）を活用し、再訪問ユーザーのTTFBをゼロにする戦略。
• <b>DNS解決時間の最小化</b>：高速なDNSプロバイダの採用、TTL値の引き上げ、dns-prefetchリソースヒントによるDNS名前解決の高速化。
• <b>接続時間（TCP + TLS）の最適化</b>：HTTP/3、TLS 1.3、セッション再開、preconnectヒントを活用したTCPおよびTLSハンドシェイク時間の短縮。