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

Jeremy Wagner
Barry Pollard

対応ブラウザ

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

ソース

TTFB とは何ですか？

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

ネットワーク リクエストのタイミングを可視化したものです。タイミングは、左から右に、リダイレクト、サービス ワーカーの初期化、サービス ワーカーの取得イベント、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 は、次のリクエスト フェーズの合計です。

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

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

TTFB のその他の定義

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

早期ヒントは、早期対応の新しい例にすぎません。一部のサーバーでは、メイン コンテンツが利用可能になる前にドキュメント レスポンスをフラッシュできます。これは、HTTP ヘッダーのみを使用するか、<head> 要素を使用するかによって行われます。どちらも早期ヒントと効果が似ているため、TTFB の測定対象の定義が不明確になります。

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

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

適切な 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 の最適化に関する詳細なガイドをご覧ください。