本頁面由 Cloud Translation API 翻譯而成。

第一個位元組時間 (TTFB)

Jeremy Wagner

Barry Pollard

瀏覽器支援

資料來源

什麼是 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) 會在收到第一個位元組 (包括 Early Hints) 之前進行評估。

提示提早顯示只是提早回應的最新範例。有些伺服器會在主體可用之前，先清除文件回應，這麼做的方式可能是只使用 HTTP 標頭，或是使用 <head> 元素，這兩種方式的效果都與早期提示類似，因此也模糊了 TTFB 的定義。

這項指標可用來評估瀏覽器何時收到文件可操作資料的「第一個位元組」，因此所有這些定義都可能有效。如果完整回應需要較長時間，提早傳回資料就會帶來實質價值。最重要的是瞭解您使用的工具所評估的項目，以及評估項目受到評估平台的影響程度。因此，在不同平台或技術之間比較 TTFB 的難度，取決於各平台或技術採用的功能，以及這些功能對 TTFB 測量方式的影響。

TTFB 也經常被視為伺服器或主機回應時間的指標。不過，這項作業會受到直接控制範圍以外的因素影響，例如重新導向時間、是否從 CDN 的快取中放送，或是必須經過較長的路徑才能返回原始伺服器。這在實地資料中特別明顯。實驗室測試通常會測試最終網址，並經常重複取消快取變更，因此通常不受這些因素影響。Lighthouse 會回報伺服器回應時間，而非 TTFB，以便更清楚地呈現這項資訊，但其他實驗室工具可能不會這麼做。

什麼是良好的 TTFB 分數？

由於 TTFB 會先於以使用者為中心的指標 (例如首次顯示內容所需時間 (FCP) 和最大內容繪製 (LCP)) 等) 計算，因此建議伺服器快速回應導覽要求，讓75 個百分位數的使用者都能在「良好」門檻內取得 FCP。作為粗略的參考依據，大多數網站應力求 TTFB 為 0.8 秒以下。

良好的 TTFB 值為 0.8 秒以下，不良的值為 1.8 秒以上，介於兩者之間的值則需要改善 — 良好的 TTFB 值為 0.8 秒以下，不良的值則為 1.8 秒以上。

如何評估 TTFB

您可以透過下列方式，在實驗室或實際環境中測量 TTFB。

欄位工具

實驗室工具

在 Chrome 開發人員工具的「網路」面板中
WebPageTest

在 JavaScript 中測量 TTFB

您可以使用 Navigation Timing API，在瀏覽器中測量導覽要求的 TTFB。以下範例說明如何建立 PerformanceObserver，讓系統監聽 navigation 項目並將其記錄到控制台：

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 的程式碼片段類似，只是您要查詢 'resource' 項目，而非 'navigation' 項目。這也說明瞭為何從主要來源載入的部分資源可能會傳回 0 值，因為連線已開啟，或資源會從快取中立即擷取。

如何改善 TTFB

如需改善網站 TTFB 的指南，請參閱最佳化 TTFB 的深入指南。