Time to First Byte (TTFB) の問題を特定して修正する

Time to First Byte (TTFB) の問題を見つけて修正する

この記事は、Time to First Byte (TTFB) ガイドの一部です。TTFBは、ユーザーがページをリクエストしてからブラウザがレスポンスの最初のバイトを受信するまでの時間を測定する診断メトリックです。TTFB自体は Core Web Vital ではありませんが、First Contentful Paint (FCP) と Largest Contentful Paint (LCP) の両方に直接影響します。良好なTTFBは、75パーセンタイルで800ミリ秒未満です。

前回の記事では、Time to First Byte について説明しました。基本を復習したい場合は、そこから始めるのが最適です。

この記事では、さまざまな Time to First Byte の問題を特定し、それらを修正する方法について説明します。

TTFBのヒント: ほとんどの場合、初回訪問者はサイトのDNSキャッシュを持っていないため、TTFBははるかに悪くなります。TTFBを追跡する場合、初回訪問者とリピーターを区別することは非常に理にかなっています。

ステップ 1: Search ConsoleでTTFBを確認する

「回復への第一歩は、問題があることを認めることです。」したがって、Time to First Byte を修正する前に、TTFBに本当に問題があるかどうかを確認しましょう。

残念ながら、Time to First Byte は Google Search Console では報告されないため、pagespeed.web.dev に頼ってサイトの CrUX データをクエリする必要があります。幸いなことに、手順は簡単です。pagespeed.web.dev に移動し、ページのURLを入力し、「オリジン」ボタンがチェックされていることを確認します（ホームページのデータだけでなく、サイト全体のデータが必要なため）。次に、モバイルとデスクトップを切り替えて、両方のデバイスタイプの Time to First Byte を確認します。

以下の例では、TTFBが高いために Core Web Vitals に不合格となっているサイトが表示されています。

ステップ 1b: Server-Timingヘッダーを使用してより深い洞察を得る

Server-Timing HTTPレスポンスヘッダーを使用すると、サーバーはバックエンドのパフォーマンスメトリックをブラウザに直接通信できます。これにより、サーバーログにアクセスすることなく、サーバー処理のどの部分が遅いかを正確に特定できます。

典型的な Server-Timing ヘッダーは次のようになります。

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

この例では、サーバーは3つのタイミング値を報告しています。

• db;dur=53: データベースクエリに53ミリ秒かかりました。
• app;dur=120: アプリケーションロジック（テンプレートのレンダリング、API呼び出しなど）に120ミリ秒かかりました。
• cache;desc="miss": このリクエストにはサーバーキャッシュが使用されませんでした（キャッシュミス）。

これらの値は、Chrome DevToolsの「Network」タブを開き、ドキュメントリクエストを選択し、「Timing」タブの「Server Timing」セクションまでスクロールすることで確認できます。値は、JavaScriptの PerformanceServerTiming APIを通じてもアクセスできます。

const [navigation] = performance.getEntriesByType('navigation');
if (navigation.serverTiming) {
  navigation.serverTiming.forEach(entry => {
    console.log(`${entry.name}: ${entry.duration}ms (${entry.description})`);
  });
}

サーバーがまだ Server-Timing ヘッダーを送信していない場合は、追加することを検討してください。ほとんどのWebフレームワークでは簡単に行えます。PHPでは、出力の前にヘッダーを追加できます。

header('Server-Timing: db;dur=' . $dbTime . ', app;dur=' . $appTime);

Node.jsとExpressの場合:

res.setHeader('Server-Timing', `db;dur=${dbTime}, app;dur=${appTime}`);

Server-Timing ヘッダーは、実際のユーザーが体験するTTFBとサーバー側のパフォーマンスを関連付けることができるため、Real User Monitoring (RUM) と組み合わせると特に便利です。完全なレスポンスの準備ができる前にリソースヒントを送信することで、知覚されるTTFBをさらに短縮できる 103 Early Hints についての詳細もご覧ください。

ステップ 2: RUMトラッキングを設定する

Time to First Byte は扱いづらいメトリックです。実環境では他の要因がTTFBの変動に寄与するため、TTFBを測定するために合成テストだけに頼ることはできません。上記のすべての質問に対する答えを得るには、実環境でデータを測定し、Time to First Byte で発生する可能性のある問題をログに記録する必要があります。これは Real User Monitoring (RUM) と呼ばれ、RUMトラッキングを有効にする方法はいくつかあります。私たちはこれらのユースケースのために CoreDash を開発しました。CoreDashは、低コストで高速かつ効果的なRUMツールであり、その役割を果たします。もちろん、他にも多くのRUMソリューションがあり、それらも（価格は高くなりますが）同様に機能します。

TTFBの考え方: Webサーバーをレストランのキッチン、Webページをリクエストするユーザーを注文する空腹の客と想像してください。Time to First Byte (TTFB) は、客が注文してからキッチンが料理の準備を始めるまでの時間です。
つまり、TTFBは食事全体がどれだけ速く調理され (First Contentful Paint)、提供されるか (Largest Contentful Paint) ではなく、最初の要求に対してキッチンがどれだけ反応が良いかに関するものです。
RUMトラッキングは、食事体験を理解するために客にアンケートを取ることに似ています。キッチンから離れた席の客はウェイターの注意を引くのが遅れてサービスが遅くなったり、リピーターは優遇される一方で新規客はテーブルに着くまで長く待たされたりすることがわかるかもしれません。

ステップ 2b: パフォーマンスのベースラインを確立する

変更を加える前に、TTFBのベースラインを確立します。後で最適化の有効性を測定するのに役立つため、次のディメンション全体で75パーセンタイルのTTFBを記録します。

1. 全体のTTFB（モバイルとデスクトップを個別に）: 各デバイスタイプの75パーセンタイルを取得します。
2. トラフィック別の上位10ページ: トラフィックの多いページのTTFBを個別に記録します。
3. 新規訪問者 vs. リピーター: 初回訪問者は、DNSと接続のオーバーヘッドのため、通常TTFBが高くなります。
4. トラフィック別の上位5か国: サーバーへの地理的な距離はTTFBに大きく影響します。
5. TTFBサブパートの内訳: 各サブパート（待機、キャッシュ、DNS、接続、リクエスト）の75パーセンタイルを記録します。

これらの数値をスプレッドシートに記録します。各最適化を実装した後、結果を比較する前に、十分なRUMデータを収集するために少なくとも7日間待ちます。良いアプローチは、一度に1つのTTFBサブパートに取り組み、測定してから、次のサブパートに進むことです。

ステップ 3: Time to First Byteの問題を特定する

Googleの Chrome User Experience Report (CrUX) は貴重なフィールドデータを提供しますが、TTFBが高い原因についての具体的な詳細は提供しません。TTFBを効果的に改善するには、より詳細なレベルで何が起きているかを正確に知る必要があります。この時点で、全体的に不合格なTTFBと、特定の条件下で不合格なTTFBを区別することは理にかなっています（実際には常に混在していますが）。

3.1 TTFBが全体的に不合格である

1. 一般的な不十分な「リクエスト時間」を確認する: 不十分なリクエスト時間は、「問題」がサーバーがページを生成するのにかかる時間にあることを意味します。これは、TTFBスコアが悪い最も一般的な原因です。
2. 他の不十分なTTFBサブパートを確認する: TTFBは単一のメトリックではなく、それぞれに独自の最適化の可能性がある複数の部分に分解できます。待機時間 (waiting duration)、キャッシュ期間 (cache duration)、DNSルックアップ期間 (DNS lookup duration)、または 接続期間 (connection duration) が遅い場合は、サーバー設定を調整するか、より高品質のホスティングを探す必要があります。

3.2 特定の条件下でTTFBが不合格になる

1. 国別セグメンテーション: 高いTTFBの地理的分布を理解することは、特にグローバルなオーディエンスを持つWebサイトにとって重要です。（CDNエッジキャッシュなしで）1つの国の1つのサーバーからページを提供している場合、ユーザーの場所とWebサイトをホストしているサーバーとの間の物理的な距離があらゆる種類の遅延を引き起こし、TTFBに影響を与えます。世界中のユーザーにコンテンツを近づけるために、Cloudflareの設定 または別のCDNの導入を検討してください。
   
2. キャッシュセグメンテーション: キャッシングは、HTMLのサーバー側生成をスキップすることでTTFBを削減できます。残念ながら、多くの理由でキャッシュが無効になったりバイパスされたりすることは一般的です。たとえば、ログインユーザー、ショッピングカートページ、クエリ文字列を持つページ（Google広告など）、検索結果ページ、チェックアウトページなどではキャッシュが無効になる場合があります。Webサイトが（エッジ）キャッシュを使用している場合は、RUMトラッキングを使用してキャッシュヒット率を確認してください。
   
3. ページ（クラスター）セグメンテーション: ページまたはページタイプ間の Time to First Byte パフォーマンスの違い（または違いの欠如）も、特定する必要がある事項です。どのページがTTFBメトリックに不合格であるかを知ることで、Time to First Byte を改善する方法についての貴重な洞察が得られます。
   
4. リダイレクトセグメンテーション: リダイレクト時間はTTFBに直接加算されます。各リダイレクトにより、Webサーバーがページの読み込みを開始できるようになるまでに追加の時間が発生します。不要なリダイレクトを測定して排除することで、TTFBを改善できます。リダイレクトの最適化について詳しくは、TTFBの待機時間サブパートに関するガイドをご覧ください。
   
5. その他のセグメンテーション: 上記の変数によるセグメンテーションは通常の疑わしい箇所をカバーしていますが、すべてのサイトはユニークであり、独自の課題があります。幸いなことに、RUMトラッキングは、デバイスRAM、ネットワーク速度、デバイスタイプ、オペレーティングシステム、カスタム変数など、さらに多くの変数によるセグメンテーションを可能にするように設計されています。

ステップ 4: 問題にズームインして修正する

Time to First Byte (TTFB) のサブパートは次のとおりです。

• 待機 + リダイレクト（または waiting duration）
• ワーカー + キャッシュ（または cache duration）
• DNS（または DNS duration）
• 接続（または connection duration）
• リクエスト（または request duration）

ステップ 5: 一般的なTTFBの問題に対するクイック修正チェックリスト

TTFBに最も寄与しているサブパートに基づいて、最も一般的な修正のクイックリファレンスを以下に示します。

JavaScriptでTTFBを測定する

Navigation Timing API を使用して、ブラウザで直接完全なTTFBとそのサブパートを測定できます。次のスニペットは、TTFBを計算し、各サブパートをログに記録します。

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  const activationStart = nav.activationStart || 0;

  const ttfb = nav.responseStart - activationStart;
  const waitingDuration = (nav.workerStart || nav.fetchStart) - activationStart;
  const cacheDuration = nav.domainLookupStart - (nav.workerStart || nav.fetchStart);
  const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;
  const connectionDuration = nav.connectEnd - nav.connectStart;
  const requestDuration = nav.responseStart - nav.requestStart;

  console.log('TTFB:', ttfb.toFixed(0), 'ms');
  console.log('  Waiting:', waitingDuration.toFixed(0), 'ms');
  console.log('  Cache:', cacheDuration.toFixed(0), 'ms');
  console.log('  DNS:', dnsDuration.toFixed(0), 'ms');
  console.log('  Connection:', connectionDuration.toFixed(0), 'ms');
  console.log('  Request:', requestDuration.toFixed(0), 'ms');
}).observe({
  type: 'navigation',
  buffered: true
});

このコードは、CoreDashのようなツールがTTFB属性パネルに表示するのと同じ内訳を提供します。このスニペットをブラウザのコンソールで実行すると、単一のページ読み込みに対する即時の測定値が得られますが、RUMツールは数千人の実際のユーザーからこのデータを収集して、信頼性の高い75パーセンタイルの値を生成します。

詳細情報: 最適化ガイド

TTFBを改善する特定の最適化手法については、次の関連ガイドをご覧ください。

• 103 Early Hints: 完全なレスポンスの準備ができる前にリソースヒントを送信し、サーバーがまだ処理中の間にブラウザが重要なリソースの読み込みを開始できるようにします。
• パフォーマンスのためにCloudflareを設定する: CloudflareのCDN、キャッシュ、エッジ機能を設定して、グローバルなオーディエンスのTTFBを削減します。

TTFBサブパート: 詳細記事

Time to First Byte の各サブパートには、独自の最適化戦略があります。RUMデータがボトルネックとして特定している特定の領域を調べてください。

• 待機時間 (Waiting Duration): リダイレクト、ブラウザのキューイング、HSTSの最適化。
• キャッシュ期間 (Cache Duration): Service Workerのパフォーマンス、ブラウザキャッシュ、bfcache。
• DNS期間 (DNS Duration): DNSプロバイダーの選択、TTL設定、dns-prefetch。
• 接続期間 (Connection Duration): TCPハンドシェイク、TLSの最適化、HTTP/3、preconnect。