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

Jeremy Wagner
Barry Pollard

対応ブラウザ

  • 43
  • 12
  • 35
  • 11

ソース

<ph type="x-smartling-placeholder">

TTFB とは

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

<ph type="x-smartling-placeholder">
</ph> ネットワーク リクエストのタイミングの可視化。左から順に、リダイレクト、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 です。 <ph type="x-smartling-placeholder">
</ph> ネットワーク リクエストのフェーズと関連するタイミングの図。TTFB は startTime から responseStart までの経過時間を測定します。

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

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

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

TTFB のその他の定義

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

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

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

TTFB は、サーバーやホストの応答時間の指標とも考えられます。ただし、リダイレクト時間、CDN によるキャッシュ ヒットから配信されているかどうか、配信元サーバーに戻るまでの所要時間など、直接制御できない要因の影響を受けます。これはフィールド データで特に顕著です。ラボテストでは、通常、最終 URL がテストされ、多くの場合、キャッシュの変更の否定が繰り返し行われるため、これらの要因による影響は小さくなります。Lighthouse では、この点を明確にするために TTFB ではなくサーバーの応答時間をレポートしますが、他のラボツールでは確認できない可能性があります。

優れた TTFB スコアとは

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

<ph type="x-smartling-placeholder">
</ph> <ph type="x-smartling-placeholder"></ph> 良好な TTFB 値は 0.8 秒以下で、低値は 1.8 秒を超えていて、その中間値は改善が必要
良好な TTFB 値は 0.8 秒以下で、低値は 1.8 秒より大きくなっています。

TTFB の測定方法

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

フィールド ツール

ラボツール

JavaScript で TTFB を測定する

Navigation Timing API を使用すると、ブラウザでのナビゲーション リクエストの TTFB を測定できます。次の例は、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 の値を返す場合があることも考慮されます。これは、接続がすでに開いているか、リソースがキャッシュから即座に取得されているためです。

<ph type="x-smartling-placeholder">

TTFB を改善する方法

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