第一個位元組時間 (TTFB)

瀏覽器支援

  • 43
  • 12
  • 35
  • 11

資料來源

什麼是 TTFB?

TTFB 是一種指標,用來測量從資源要求到回應第一個位元組開始到回應之間所經過的時間。

網路要求時間的圖表。從左到右的時間為 Redirect、Service Worker Init、Service Worker Fetch 事件、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 會測量 startTimeresponseStart 之間的經過時間。

TTFB 是下列要求階段的總和:

  • 重新導向時間
  • Service Worker 啟動時間 (如適用)
  • DNS 查詢
  • 連線與 TLS 交涉
  • 要求,直到回應的第一個位元組為止

縮短連線設定時間和後端的延遲時間可以降低 TTFB。

TTFB 的其他定義

先前的定義是傳統定義,但新推出了「早期提示」,屬於「第一個位元組」不利於辯論firstInterimResponseStart 是新的 responseStart 時間項目,用於區分兩者,但只有 Chrome 和以 Chromium 為基礎的瀏覽器支援此功能。因此,有些瀏覽器和工具 (包括 CrUX) 會測量到接收第一個位元組為止,包括早期提示。

Early Hints 才是較新的例子,有助於及早回應。有些伺服器允許在主要主體出現前 (無論是只使用 HTTP 標頭,或是使用 <head> 元素) 清除文件回應,兩者的效果都與早期提示類似,因此也會雲端 TTFB 測量結果的定義。

測量「第一個位元組」時文件收到的可操作資料中,所有定義皆可視為有效;如果完整回應需要更多時間,及早傳回資料才是真正的價值。最重要的是,瞭解您目前採用的評估工具為何,以及該平台會受到何種影響。導致難以根據不同平台或技術比較 TTFB,因為所使用的功能及這種差異對採用的 TTFB 評估作業有何影響。

TTFB 通常也視為伺服器或主機回應時間的指標。不過,這將會受到直接控制以外的因素影響,例如重新導向時間、其放送來源為 CDN 的快取命中,或需要更長的時間傳回來源伺服器。這在現場資料中特別明顯:由於結束網址通常會經過測試,且經常會多次針對快取變更進行否定,因此實驗室測試通常不受這些因素的影響。Lighthouse 會回報伺服器回應時間 (而非 TTFB),以便更清楚瞭解,但其他研究室工具可能不盡然。

TTFB 分數的理想程度為何?

以使用者為中心的指標 (例如首次內容繪製 (FCP)最大內容繪製 (LCP)) 之前,我們會建議伺服器回應導覽要求的速度足夠,以便讓 75 個百分位數的使用者在「良好」狀態中體驗 FCP門檻。大部分網站都應該盡量讓 TTFB 達到 0.8 秒以下,

理想的 TTFB 值為 0.8 秒或小於 1.8 秒,或是有任何需要改善
良好的 TTFB 值為 0.8 秒或小於 1.8 秒。

如何測量 TTFB

TTFB 可在研究室欄位中測量,如下所示:

現場工具

研究室工具

在 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 的程式碼片段,但不是查詢 'navigation' 項目,而是改為查詢 'resource' 項目。這也考量到部分從主要來源載入的資源,可能會傳回 0 的值,因為連線已開啟,或系統會立即從快取擷取資源。

如何改善 TTFB

若要瞭解如何改善網站的 TTFB,請參閱最佳化 TTFB 的深入指南。