最初のバイトまでの時間（TTFB）

Jeremy Wagner
Barry Pollard

対応ブラウザ

  • Chrome: 43.
  • Edge: 12。
  • Firefox: 35.
  • Safari: 11.

ソース

TTFB とは

TTFB は、リソースのリクエストからレスポンスの最初のバイトが到着するまでの時間を測定する指標です。

ネットワーク リクエストのタイミングを可視化した図。左から順に、リダイレクト、Service Worker の初期化、Service Worker 取得イベント、HTTP キャッシュ、DNS、TCP、リクエスト、早期ヒント（103）、レスポンス（アンロードのプロンプトと重なる）、処理、読み込みです。関連するタイミングは、redirectStart と redirectEnd、fetchStart、domainLookupStart、domainLookupEnd、connectStart、secureConnectionStart、connectEnd、requestStart、interimResponseStart、responseStart、unloadEventStart、unloadEventEnd、responseEnd、domInteractive、domContentLoadedEventStart、domContentLoadedEventEnd、domComplete、loadEventStart、loadEventEnd です。
ネットワーク リクエストのフェーズとそれに関連するタイミングを示す図。TTFB は、startTime と responseStart の間の経過時間を測定します。

TTFB は、次のリクエスト フェーズの合計です。

  • リダイレクト時間
  • Service Worker の起動時間（該当する場合）
  • DNS ルックアップ
  • 接続と TLS ネゴシエーション
  • リクエスト（レスポンスの最初のバイトが到着するまで）

接続のセットアップ時間とバックエンドのレイテンシを短縮すると、TTFB を短縮できます。

TTFB のその他の定義

上記の定義は従来の定義ですが、早期ヒントの導入により、「最初のバイト」と見なされるものが議論されています。firstInterimResponseStart は、これらの違いを区別するために responseStart に追加された新しいタイミング エントリですが、Chrome と Chromium ベースのブラウザでのみサポートされています。そのため、一部のブラウザやツール（CrUX など）では、早期ヒントを含む最初のバイトが受信されるまで測定されます。

早期ヒントは、早期対応の新しい例にすぎません。サーバーによっては、HTTP ヘッダーのみ、または <head> 要素のいずれかを使用して、本文が利用可能になる前にドキュメントのレスポンスのフラッシュが行われる場合があります。どちらも実質的に Early Hints と類似していると見なされ、TTFB の測定内容の定義もクラウド化されます。

ドキュメントの実行可能なデータの「最初のバイト」がブラウザによって受信されたときの測定値として、これらの定義はすべて有効と見なすことができます。完全なレスポンスに時間がかかる場合は、データを早めに返すことに大きな価値があります。最も重要なことは、使用しているツールが測定する指標と、測定対象のプラットフォームによってその指標がどのように影響を受けるかを理解することです。そのため、使用する機能と、使用される TTFB 測定にどのように影響するかに応じて、異なるプラットフォームやテクノロジー間で TTFB を比較することは困難です。

TTFB は、サーバーまたはホストのレスポンス時間の指標と見なされることもあります。ただし、リダイレクト時間、CDN のキャッシュヒットから提供されるかどうか、オリジン サーバーに返す際に長い経路をたどる必要があるかどうかなど、直接制御できない要因によって影響を受けます。これは、フィールドデータで特に顕著です。通常、ラボテストでは最終的な URL がテストされ、キャッシュ変更が繰り返し無効になるため、これらの要因の影響は小さくなります。Lighthouse では、この点を明確にするために TTFB ではなくサーバーの応答時間をレポートしますが、他のラボツールでは確認できない可能性があります。

適切な TTFB スコアとは

TTFB は、コンテンツの初回ペイント（FCP）やLargest Contentful Paint（LCP）などのユーザー中心の指標よりも先行するため、サーバーからナビゲーション リクエストに十分な速さで応答し、75 パーセンタイルのユーザーが「良好」のしきい値内の FCP を体験できるようにすることをおすすめします。目安として、ほとんどのサイトでは TTFB を 0.8 秒以下にすることをおすすめします。

TTFB の値が 0.8 秒未満であれば良好、1.8 秒を超える場合は不良です。その間の値は改善が必要です
TTFB の良好な値は 0.8 秒以下で、低い値は 1.8 秒を超えています。

TTFB を測定する方法

TTFB は、ラボまたは現場で次の方法で測定できます。

フィールド ツール

ラボツール

JavaScript で TTFB を測定する

ブラウザのナビゲーション リクエストの TTFB は、Navigation Timing API を使用して測定できます。次の例は、navigation エントリをリッスンしてコンソールにログに記録する PerformanceObserver を作成する方法を示しています。

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

  console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({
  type: 'navigation',
  buffered: true
});

web-vitals JavaScript ライブラリを使用すると、ブラウザで TTFB をより簡潔に測定することもできます。

import {onTTFB} from 'web-vitals';

// Measure and log TTFB as soon as it's available.
onTTFB(console.log);

リソース リクエストを測定する

TTFB は、ナビゲーション リクエストだけでなく、すべてのリクエストに適用されます。特に、クロスオリジン サーバーでホストされているリソースは、それらのサーバーと接続を確立する必要があるため、レイテンシが発生する可能性があります。フィールド内のリソースの TTFB を測定するには、PerformanceObserver 内で Resource Timing API を使用します。

new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();

  for (const entry of entries) {
    // Some resources may have a responseStart value of 0, due
    // to the resource being cached, or a cross-origin resource
    // being served without a Timing-Allow-Origin header set.
    if (entry.responseStart > 0) {
      console.log(`TTFB: ${entry.responseStart}`, entry.name);
    }
  }
}).observe({
  type: 'resource',
  buffered: true
});

上のコード スニペットは、ナビゲーション リクエストの TTFB を測定するために使用されるコード スニペットに似ていますが、'navigation' エントリをクエリする代わりに 'resource' エントリをクエリします。また、接続がすでに開かれているか、リソースがキャッシュから即座に取得されるため、プライマリ オリジンから読み込まれた一部のリソースが 0 の値を返す可能性があることも考慮しています。

TTFB を改善する方法

サイトの TTFB を改善する方法については、TTFB の最適化に関する詳細なガイドをご覧ください。