第一個位元組時間 (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) 會在收到第一個位元組 (包括 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 的深入指南。