Time To First Byte (TTFB) とは何か、そしてその改善方法

Time to First Byte (TTFB) は、ブラウザがページをリクエストしてから、サーバーからのレスポンスの最初のバイトを受信するまでの時間をミリ秒単位で測定します。優れたTTFBは、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は待機時間とも呼ばれます。TTFBは、Webサーバーの応答性と、ユーザーとそのサーバー間のネットワークパスを測定する方法です。TTFBは基礎となる指標です。つまり、TTFBに追加された時間は、Largest Contentful PaintとFirst Contentful Paintにも追加されます。TTFBで節約された1ミリ秒ごとに、これら両方のペイント指標でも1ミリ秒が節約されます。

TTFBはCore Web Vitalsではない

これを明確に述べておくことが重要です：TTFBは3つのCore Web Vitalsの1つではありません。Core Web Vitalsは、Largest Contentful Paint (LCP)、Interaction to Next Paint (INP)、およびCumulative Layout Shift (CLS)で構成されています。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を修正することでページスピードとユーザーエクスペリエンス (UX) が大幅に向上します。

訪問者にとっての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が低いからといって必ずしも優れたユーザーエクスペリエンス (UX) を意味するわけではありません。すべてのバイトがすばやくダウンロードされたとしても、ブラウザが大量のJavaScriptを処理したり、複雑なレイアウトをレンダリングしたりする必要がある場合、Webページの表示に長い時間がかかる可能性があります。

優れたTTFBスコアとは？

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

• 800ミリ秒未満のTTFBは良好と見なされます。
• 800から1800ミリ秒のTTFBは改善が必要です。
• 1800ミリ秒を超えるTTFBは不良と見なされ、すぐに改善する必要があります。

現実世界への影響: T-Mobileのケーススタディ

T-Mobileは、より広範なパフォーマンス最適化イニシアチブの一環として、Time to First Byteの削減に多大な投資を行いました。結果は驚くべきものでした：訪問から注文へのコンバージョンが60%増加しました。エッジレンダリングされたページと積極的なサーバーサイドキャッシュに移行することで、T-Mobileはユーザーが最初のバイトを待つ時間を大幅に短縮し、それがより高速なLCP、より高速なFCP、そして測定可能なほど優れたユーザーエクスペリエンス (UX) へと波及しました。このケーススタディは、TTFBの最適化が単なる技術的な演習ではないことを示しています。それはビジネスの成果に直接影響します。

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

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

ブラウザのリクエスト時間は、ユーザーのブラウザがHTTPリクエストを送信してから、そのリクエストがWebサイトをホストしているサーバーに到達するまでに経過した時間です。この部分のTTFBは、Webサイトの直接的な制御の及ばない部分が多く、以下の要因に大きく依存します：

• ユーザーのインターネット速度。
• ネットワークインフラストラクチャの品質。
• ユーザーとサーバー間の物理的な距離。

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

サーバー上: レスポンスの処理と準備

サーバーがリクエストを受信すると、レスポンスを生成するために動作するため、時計の針が進みます。この段階は、ほとんどの開発者が集中しがちであり、最適化の取り組みが最も大きな影響を与える可能性がある場所です。考慮すべき要因は次のとおりです：

• サーバーの機能: 強力なハードウェア（CPU、RAM）、効率的なソフトウェア（Webサーバー、データベース）、および最適化された構成がすべて重要です。
• データベースの期間: リクエストでデータベースからデータをフェッチする必要がある場合、遅いクエリが大きなボトルネックになる可能性があります。
• コードの最適化: 記述が不十分なサーバーサイドコード（非効率的なスクリプトなど）は、処理時間の長期化につながる可能性があります。
• キャッシュ戦略: 効果的なキャッシュ（サーバーサイドキャッシュやコンテンツデリバリネットワークの使用など）は、リピートリクエストの処理の負担を大幅に減らすことができます。

ブラウザに戻る: 最初のバイトの配信

処理後、サーバーは最初のバイトから始まるレスポンスをユーザーのブラウザに送り返します。

• 最初の段階と同様に、ネットワークの状態と距離もここで役割を果たします。
• CDNは、コンテンツをユーザーの近くにキャッシュして移動時間を最小限に抑えるため、この段階で特に有益です。
• リダイレクトはこの時点で処理され、余分な遅延を伴ってプロセスが繰り返されます。

Time To First Byteの技術的な段階

ブラウザでの「リクエストからレスポンスまでのパス」と同様に、ナビゲーションリクエストのTime To First Byteは、Navigation Timing APIで測定でき、5つのサブパートに分類できます。

1. リダイレクト時間: リソースが新しい場所に移動された場合、リダイレクト時間がリソースのTTFBに追加されます。
2. Workerとキャッシュ時間: インターネットからリソースをフェッチする前に、ブラウザはまず自身のキャッシュまたはWorker（Workerが設定されている場合）を介してリソースを検索しようとします。
3. DNSルックアップ時間: 次に、ブラウザはドメイン名（www.example.com）をIPアドレスに変換するためにDNSルックアップを実行する必要がある場合があります。
4. TCP接続時間: その後、ブラウザはサーバーに接続し、いくつかのチェックを実行します。
5. SSLハンドシェイク: その後、ブラウザとサーバーは通信を暗号化します。
6. サーバーのレスポンス: 最後に、サーバーはHTMLを送信する必要があります。最初にHTMLを生成する必要がある場合があります。

Time To First Byte (TTFB) を測定する方法

PageSpeedのヒント: すべてのリソースには独自のTime to First Byteがあります。ただし、このコンテキストでは、メインページのTime to First Byteについて話しています。

Time to First Byteは、デバイスや場所が異なるさまざまなユーザー間で大きく変動する可能性があります。そのため、デスクトップコンピュータからTime to First Byteを自己測定することは、おそらく良い考えではありません。PingdomやGTMetrixなどのツールを使用することも、同じ理由で信頼性がありません。

Time To First Byteを測定する最良の方法は、訪問者からReal User Metrics (RUM) データを収集することです。以下のコードを使用して自分でこれを行うか、CoreDashのようなRUMツールを使用することができます。

合成ツールでTTFBを測定する

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

CrUXデータでTTFBを測定する

CrUX (Chrome User Experience Report) は、Webサイトの実際のパフォーマンスデータを含む、Googleが公開しているデータセットです。GoogleはCrUXデータセットを使用して、Core Web Vitalsに合格しているかどうかを判断します。

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

JavaScriptでTTFBを測定する

JavaScriptでTime to First Byte (TTFB) を測定するには、Navigation Timing APIを使用できます。ナビゲーションエントリをリッスンし、responseStartプロパティをコンソールに記録するPerformanceObserverを作成できます。responseStartプロパティは、レスポンスの最初のバイトが受信されたときのタイムスタンプを表します。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は、ネットワークパネルに直接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を使用すると、サーバーはリクエストを受信した直後に部分的なレスポンスを送信します。この部分的なレスポンスには、プリロードまたは事前接続するリソースをブラウザに指示するLinkヘッダーが含まれています。ブラウザは、完全な200レスポンスを待つ間にこれらのヒントに基づいて動作します。

これにより、無駄な待機時間が生産的な読み込み時間に効果的に変わります。103 Early Hintsはドキュメント自体のTTFBを低下させることはありませんが、リソースの発見においてブラウザに有利なスタートを切らせることで、LCPやFCPなどの後続の指標に対するTTFBの体感的な影響を軽減します。

103 Early Hintsのサーバー構成例

多くのCDNとWebサーバーが現在、103 Early Hintsをサポートしています。以下は、HTMLにあるLinkヘッダーとpreload/preconnectタグから103 Early Hintsを自動的に生成するCloudflareを使用した例です：

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を排除するか

ページがプリレンダリングされると、ブラウザは非表示のタブでそのページを読み込み、完全にレンダリングします。その後、ユーザーがリンクをクリックすると、プリレンダリングされたページが即座にスワップインされます。結果として、測定されたTTFBは0ミリ秒になります。これは理論上の数値ではありません。corewebvitals.ioのCoreDashのRUMデータは、Speculation Rulesによるプリレンダリングされたナビゲーションが0msのp75 TTFBを示すことを確認しています。

プリフェッチは、より軽量な代替手段です。ページを完全にレンダリングする代わりに、ブラウザは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をまだサポートしていないブラウザの場合、フォールバック (fallback) としてquicklinkなどの軽量スクリプトを使用できます。私たちのSpeculation Rules Generatorを使用して、サイトに適切な構成を作成してください。

ホスティングはTime to First Byteにどのように影響するか？

ホスティングは、複数の方法でTime to First Byteに影響を与えます。より優れたホスティングに投資することで、通常、何も変更せずにTime to First Byteをすぐに改善できます。特に、低予算の共有ホスティングから、適切に構成および管理された仮想サーバーに切り替える場合、TTFBは劇的に改善される可能性があります。

ホスティングのヒント: より優れたホスティングには、より高速な処理、より優れたネットワーク速度、より多くのより高速なサーバーメモリが含まれます。高価なホスティングが常に優れたホスティングに等しいとは限りません。共有ホスティングサービスの多くのアップグレードでは、ストレージが増えるだけで、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のヒント: DNS、TCP、およびSSLは通常、安価なホストを使用している場合、またはCDNを使用せずにグローバルオーディエンスにサービスを提供している場合により大きな問題になります。RUMトラッキングを使用してグローバルTTFBを表示し、TTFBをサブパートに分割します。

高速なDNSプロバイダーを使用します。すべてのDNSプロバイダーが他のプロバイダーと同じくらい高速なわけではありません。一部の（無料）DNSプロバイダーは、他の（無料）DNSプロバイダーよりも遅いだけです。たとえば、Cloudflareは、世界最速のDNSプロバイダーの1つを無料で提供します。

DNSのTTLを増やす。別の方法は、Time to Live (TTL) 値を増やすことです。TTLは、ルックアップをキャッシュできる期間を決定する設定です。TTLが高いほど、ブラウザが別のDNSルックアップを実行する必要がある可能性が低くなります。ISPもDNSをキャッシュすることに注意することが重要です。

TCPのスピードアップ

TTFBの「TCP部分」は、Webサーバーへの初期接続です。接続時に、ブラウザとサーバーはデータの交換方法に関する情報を共有します。地理的に近いサーバーに接続し、サーバーに十分な空きリソースがあることを確認することで、TCPを高速化できます。NGINXのような軽量サーバーに変更すると、TTFBのTCP部分が高速化される場合があります。多くの場合、CDNを使用するとTCP接続が高速化されます。

SSL/TLSのスピードアップ

TCP接続が確立されると、ブラウザとサーバーは暗号化を通じて接続を保護する必要があります。より高速で新しく軽量なプロトコル（SSL暗号）を使用し、地理的にWebサーバーに近づくことで（TLSネゴシエーションにはかなりの数の往復が必要になるため）、これを高速化できます。CDNは非常によく構成されており、世界中に複数のサーバーがあることが多いため、CDNを使用するとSSL接続時間が改善されることがよくあります。特にTLS 1.3は、TLSネゴシエーションをできるだけ短くするように設計されています。

TTFBの改善方法: サーバーサイドをスピードアップする

ページキャッシュ

Time to First Byteを高速化する最も効率的な方法は、サーバーキャッシュからHTMLを提供することです。フルページキャッシュを実装する方法はいくつかあります。最も効果的な方法は、たとえばNGINXキャッシュモジュールを使用したり、Varnishをリバースキャッシュプロキシとして使用したりして、Webサーバーレベルでこれを直接行うことです。

また、フルページをキャッシュするさまざまなCMSシステム用のプラグインも多数あり、Next.jsのような多くのSPAフレームワークには、さまざまな無効化戦略とともに独自のフルページキャッシュの実装があります。

独自のキャッシュを実装したい場合、基本的な考え方はシンプルです。クライアントがページを要求したときに、キャッシュフォルダにページが存在するかどうかを確認します。存在しない場合は、ページを作成し、キャッシュに書き込んで、通常どおりページを表示します。そのページへの次のリクエストでは、キャッシュファイルが存在し、キャッシュからページを直接提供できます。

部分キャッシュ

部分キャッシュの考え方は、ページまたはリソース（API呼び出し、データベースの実行結果など）の頻繁に使用される、遅い、または負荷の高い部分をキャッシュして、高速に取得することです。これにより、ページを生成する際のボトルネックが解消されます。これらのタイプの最適化に興味がある場合は、次の概念を調べる必要があります：メモリキャッシュ、オブジェクトキャッシュ、データベースキャッシュ、オブジェクトリレーショナルマッピング (ORM) キャッシュ、コンテンツフラグメントキャッシュ、およびオペコードキャッシュ。

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

キャッシュファイルが存在しないため、ページの大部分が動的であるため、またはその他の問題が発生したために、ページを（部分）キャッシュから提供できない場合があります。そのため、アプリケーションコードを最適化する必要があります。これがどのように行われるかは、アプリケーションに完全に依存します。これは、コードの遅い部分の書き直しと最適化に基づいています。

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

ほとんどの場合、非効率的なデータベースクエリがTime to First Byteが遅い根本原因です。まず、「スロークエリ」と「インデックスを使用していないクエリ」をディスクに記録することから始めます。それらを分析し、インデックスを追加するか、専門家にデータベースチューニングを依頼して、これらの問題を修正します。詳細については、MongoDB Performance AdvisorおよびMySQL Slow Query Logを参照してください。

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

私が望む以上に遭遇する悪い習慣は、Webアプリケーションとデータストレージ間の通信の遅さによって引き起こされるTime to First Byteの遅延です。これは通常、データストレージをクラウドAPIにアウトソーシングした大規模なサイトでのみ発生します。

TTFBの改善方法: クライアントサイドをスピードアップする

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

クライアントサイドのキャッシュでは、ユーザーのブラウザが、画像やスクリプトなど、すでにアクセスしたリソースを保存します。そのため、ユーザーがWebサイトに戻ったときに、ブラウザはそれらを再度ダウンロードするのではなく、キャッシュされたリソースをすばやく取得できます。これにより、サーバーに対して行われるリクエストの数が大幅に減少し、その結果、TTFBが減少する可能性があります。

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

ページのHTMLをクライアント側で完全にキャッシュすることを検討できます。サーバーリクエストが必要ないため、これによりTTFBが劇的に減少します。欠点は、ページがブラウザのキャッシュに入ると、ページキャッシュの有効期限が切れるまで、ページのライブバージョンの更新がユーザーに表示されないことです。

Service Workers

Service Workersは、ユーザーのブラウザのバックグラウンドで実行されるスクリプトであり、ブラウザによって行われたネットワークリクエストをインターセプトできます。つまり、Service WorkersはHTML、画像、スクリプト、スタイルシートなどのリソースをキャッシュできるため、ユーザーがWebサイトに戻ったときに、ブラウザはそれらを再度ダウンロードするのではなく、キャッシュされたリソースをすばやく取得できます。

ページプリフェッチ

ブラウザのサポートが限られているため、Speculation Rules APIを使用しない場合は、quicklinkという小さなスクリプトを使用できます。これにより、表示されているビューポート内のすべてのリンクがプリフェッチされ、これらのリンクのTime To First Byteがほぼなくなります。

quicklinkの欠点は、より多くのブラウザリソースを必要とすることですが、当面の間は、ブラウザのカバレッジの点でSpeculation Rules APIよりも優れています。

TTFBの改善方法: CDNを使用する

コンテンツデリバリネットワークまたはCDNは、サーバーの分散ネットワークを使用してリソースをユーザーに配信します。これらのサーバーは通常、地理的にエンドユーザーに近く、速度が高度に最適化されています。Cloudflareを使用している場合は、Core Web Vitalsの最適なパフォーマンスのためにCloudflareを構成する方法に関するガイドを確認してください。

CDNは、Time to First Byteの6つの部分のうち5つを改善するのに役立ちます：

• リダイレクト時間: ほとんどのCDNは、エッジでリダイレクトをキャッシュしたり、エッジWorkerを使用して、オリジンサーバーに接続せずにリダイレクトを処理したりできます。
• DNSルックアップ時間: ほとんどのCDNは、現在のDNSサーバーよりもおそらく優れた、非常に高速なDNSサーバーを提供しています。
• TCP接続およびSSLハンドシェイク時間: ほとんどのCDNは非常によく構成されており、エンドユーザーへの近さと相まって、これらの構成は接続およびハンドシェイク時間を短縮します。
• サーバーのレスポンス: CDNはいくつかの方法でサーバーの応答時間を短縮できます。1つ目は、サーバーのレスポンスをエッジにキャッシュすること（フルページエッジキャッシュ）ですが、優れた圧縮（Brotli）と最新のプロトコル（HTTP/3）を提供することによっても実現します。

TTFBの改善方法: リダイレクトを避ける

リダイレクト時間はTime To First Byteに追加されます。したがって、一般的なルールとして、リダイレクトはできるだけ避けてください。リダイレクトは、リソースが1つの場所で利用できなくなり、別の場所に移動したときに発生する可能性があります。サーバーはリダイレクトレスポンスヘッダーで応答し、ブラウザはその新しい場所を試行します。

同一オリジンリダイレクト。同一オリジンリダイレクトは、自分のWebサイト上のリンクから発生します。これらのリンクを完全に制御できる必要があり、Time to First Byteに取り組むときは、これらのリンクの修正を優先する必要があります。Webサイト全体でリダイレクトを確認できるツールはたくさんあります。

クロスオリジンリダイレクト。 クロスオリジンリダイレクトは、他のWebサイトのリンクから発生します。これらに対する制御はほとんどありません。

複数リダイレクト。 複数リダイレクトまたはリダイレクトチェーンは、単一のリダイレクトがリソースの最終的な場所にリダイレクトしない場合に発生します。これらのタイプのリダイレクトは、Time to First Byteにさらなる負担をかけるため、何としても避ける必要があります。繰り返しますが、ツールを使用してこれらのタイプのリダイレクトを見つけ、修正してください。

HTTPからHTTPSへのリダイレクト。 これを回避する1つの方法は、Strict-Transport-Security ヘッダー (HSTS) を使用することです。これにより、オリジンへの最初の訪問でHTTPSが強制され、その後の訪問では直ちにHTTPSスキームを介してオリジンにアクセスするようにブラウザに指示されます。

ユーザーがWebページをリクエストすると、サーバーは別のページへのリダイレクトで応答する場合があります。このリダイレクトにより、ブラウザは新しいページに追加のリクエストを行う必要があるため、TTFBに追加の時間がかかる可能性があります。

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

1. 内部リンクを更新します。ページの場所を変更する場合は常に、そのページへの内部リンクを更新して、以前のページの場所への参照が残らないようにします。
2. サーバーレベルでリダイレクトを処理します。
3. 相対URLを使用する: 自分のWebサイトのページにリンクする場合は、絶対URLではなく相対URLを使用します。これにより、不要なリダイレクトを防ぐことができます。
4. カノニカルURLを使用する: 類似のコンテンツを持つページが複数ある場合は、カノニカルURLを使用してページの優先バージョンを示します。これにより、重複コンテンツと不要なリダイレクトを防ぐことができます。
5. 301リダイレクトを使用する: リダイレクトを使用する必要がある場合は、302リダイレクトではなく301リダイレクトを使用します。301リダイレクトは永続的なリダイレクトであり、302リダイレクトは一時的なリダイレクトです。301リダイレクトを使用すると、不要なリダイレクトを防ぐのに役立ちます。

TTFBと一緒にリソースの優先順位付けを最適化する

TTFBの削減は、読み込みパフォーマンスの物語の一部にすぎません。最初のバイトが到着すると、ブラウザはどのリソースを優先するかを知る必要があります。私たちのリソースの優先順位付けに関するガイドを読んで、fetchpriority、preload、およびpreconnectヒントが高速なTTFBと連携して、可能な限り最速のページ読み込みを実現する方法を学びましょう。さらに、ユーザーの体感的なTTFBを増加させるサードパーティのDNSルックアップと接続時間を排除するために、Google Fontsをセルフホストすることを検討してください。

現実世界のTTFBデータが示すもの

以下のデータは、CoreDash Real User Monitoringと2025 Web Almanacから取得されています。

地理的な差異は甚大である

TTFBは、ユーザーとサーバー間の物理的な距離に基づいて劇的に異なります。corewebvitals.io（ヨーロッパでホストされている）のCoreDashデータは、これを明確に示しています：

サーバーに近いヨーロッパのユーザーのTTFBは170ミリ秒未満ですが、インドのユーザーは3倍のTTFBを経験し、中国のユーザーはグレートファイアウォールと純粋な物理的距離のためにほぼ10倍のTTFB（1,468ミリ秒）になります。このデータは、グローバルエッジロケーションを備えたCDNが国際的なオーディエンスに不可欠である理由を示しています。

Speculation Rulesのプリレンダリングは0msのTTFBを提供する

CoreDashのナビゲーションタイプのデータは、Speculation Rulesを介してプリレンダリングされたページが0ミリ秒のp75 TTFBを達成することを確認しています。標準のナビゲーションは131ミリ秒、リロードは82ミリ秒（ウォーム接続の恩恵を受けている）、そして戻る/進むナビゲーションは244ミリ秒と最も遅くなっています。これにより、Speculation Rulesは、後続のページ読み込みでのTTFBを排除するための最も効果的な単一のテクニックになります。

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

corewebvitals.ioでは、モバイルユーザーのp75 TTFBは316ミリ秒であるのに対し、デスクトップでは124ミリ秒です。この2.5倍の差は、サーバーの違いではなく、モバイルネットワークの遅延によって引き起こされます。デスクトップの96.1%と比較して、モバイルページの読み込みの88.5%のみが「良好な」TTFB評価を達成しています。TTFBを最適化する場合は、常に実際のモバイルネットワークでテストしてください。

新規訪問者とリピーターは同様のTTFBを見る

このサイトでは、新規訪問者のp75 TTFBは127ミリ秒ですが、リピーターは138ミリ秒です。この類似性は、（クライアントサイドのキャッシュの利点ではなく）一貫したサーバーサイドキャッシュがTTFBパフォーマンスの主要な要因であることを示唆しています。サーバーサイドキャッシュのないサイトでは、新規訪問者とリピーターの差がはるかに大きくなる可能性があります。

グローバルTTFBは5年間停滞している

2025 Web Almanacによると、グローバルで「良好な」TTFBスコアを達成しているモバイルページはわずか44%です。この数字は2021年の41%からほとんど変わっておらず、TTFBはWeb上で最も停滞しているパフォーマンス指標となっています。一方、同じ期間にLCPは44%から59%に、INPは55%から74%に改善しました。LCPが低いサイトは、TTFBだけで平均2.27秒を費やしており、2.5秒のLCPしきい値のほぼ全体を占めています。

関連ガイド: TTFBのサブパート

Time to First Byteの各サブパートには、独自の最適化戦略があります：

• <b>TTFBの問題の修正と特定</b>: DevTools、Server-Timing、およびRUMデータを使用して、遅いTTFBの根本原因を見つけるためのステップバイステップの診断ガイド。
• <b>待機時間を短縮する</b>: TTFBに追加されるリダイレクト時間とサーバーの処理遅延を最小限に抑える方法。
• <b>キャッシュ時間を短縮する</b>: リピーターのTTFBを排除するためのブラウザキャッシュ、Service Workers、およびバック/フォワードキャッシュ (bfcache) の戦略。
• <b>DNSの時間を最小限に抑える</b>: より高速なDNSプロバイダー、増加したTTL値、およびdns-prefetchリソースヒントを使用してDNS解決を高速化する方法。
• <b>接続時間（TCP + TLS）を最適化する</b>: HTTP/3、TLS 1.3、セッション再開、およびpreconnectヒントを使用してTCPおよびTLSハンドシェイク時間を短縮します。