最佳化首次位元組的時間

瞭解如何最佳化「首次位元組時間」指標。

Jeremy Wagner
Barry Pollard

「首次位元組時間」(TTFB) 是網路效能指標，與其他有意義的使用者體驗指標 (例如「First Contentful Paint (FCP)」和「Largest Contentful Paint (LCP)」) 相較。這表示 TTFB 值偏高後，後續指標會增加時間。

建議您讓伺服器迅速回應導覽要求，讓 75 個百分位數的使用者能在「良好」門檻內體驗 FCP。大部分網站都應該盡量讓 TTFB 達到 0.8 秒以下，

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

如何測量 TTFB

在最佳化 TTFB 前，請先觀察這項做法對網站使用者的影響。基於重新導向的影響，你應該以「欄位資料」做為觀察 TTFB 的主要來源。然而，研究室式工具通常是透過最終到達網址進行評估，因此缺少這段額外延遲。

PageSpeed Insights 則是透過 Chrome 使用者體驗報告取得公開網站之欄位和研究室資訊的方法。

「瞭解真人使用者的 TTFB」會顯示在「瞭解實際使用者體驗」部分中：

PageSpeed Insights 實際使用者資料，包括 TTFB 指標的欄位資料。

伺服器回應時間稽核會顯示 TTFB 的子集：

伺服器回應時間稽核

如想瞭解更多在現場和研究室中測量 TTFB 的方法，請參閱 TTFB 指標頁面。

使用 Server-Timing 對欄位中偏高的 TTFB 進行偵錯

您可以在應用程式後端使用 Server-Timing 回應標頭，評估導致高延遲的不同後端程序。標頭值的結構是靈活的，至少接受您定義的控制代碼。選用的值包括時間長度值 (透過 dur)，以及使用者可理解的說明 (透過 desc)。

Serving-Timing 可用來評估許多應用程式後端程序，但請注意，以下幾點：

  • 資料庫查詢
  • 伺服器端轉譯時間 (如適用)
  • 磁碟搜尋次數
  • 邊緣伺服器快取命中/遺失 (如果使用 CDN)

Server-Timing 項目的所有部分都以半形冒號分隔，多個項目可以使用半形逗號分隔：

// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2

您可利用應用程式後端選擇的語言來設定標頭。以 PHP 為例，您可以將標頭設定如下：

<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);

// Perform a database query and get results...
// ...

// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);

// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStarTime) / 1e+6;

// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>

設定這個標頭後，畫面上就會顯示可用於研究室和欄位的資訊。

在這個欄位中，任何已設定 Server-Timing 回應標頭的網頁都會填入 Navigation Timing API 中的 serverTiming 屬性：

// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
  // Log the server timing data:
  console.log(entry.name, entry.description, entry.duration);
});

在研究室中，Server-Timing 回應標頭的資料會顯示在 Chrome 開發人員工具「Network」分頁的時間面板中：

Chrome 開發人員工具「網路」分頁中的伺服器時間標頭值視覺化呈現。在這張圖片中，「Server-Timing」標頭值會評估 CDN 邊緣伺服器是否在快取中找到了或失敗，以及從邊緣和原始伺服器擷取資源所需的時間。

以視覺化方式呈現 Chrome 開發人員工具網路分頁中的 Server-Timing 回應標頭。這裡的 Server-Timing 用於評估資源要求是否已達到 CDN 快取，以及要求到達 CDN 邊緣伺服器所需的時間，以及來源。

透過分析可用資料確定您的 TTFB 有問題後，就可以著手修正問題。

最佳化 TTFB 的方式

最佳化 TTFB 時，最具挑戰性的原因是，雖然網站的前端堆疊一律為 HTML、CSS 和 JavaScript，但後端堆疊可能有顯著差異。許多後端堆疊和資料庫產品都有各自的最佳化技巧。因此，本指南著重於適用於大多數架構的內容，而不是只關注堆疊專屬指南。

特定平台指南

網站採用的平台可能會對 TTFB 造成重大影響。舉例來說，外掛程式的數量、品質或所用主題會影響 WordPress 的效能。自訂平台時，其他平台也有類似影響。如需更多一般成效建議，請參閱您平台的說明文件。透過 Lighthouse 可縮短伺服器回應時間的稽核作業，也包含部分堆疊專屬指南。

託管、代管、代管

在您考慮其他最佳化方法之前，首先應考慮開始代管。這裡沒有太多具體指南，但基本原則是確保您的網站主機能處理您傳送至該網站的流量。

共用代管服務的速度通常較慢。如果您經營的小型個人網站主要提供靜態檔案，這可能沒有問題，而且後續的最佳化技巧可協助您盡量降低 TTFB。

不過，如果您執行的一個大型應用程式，有許多使用者需要個人化服務、資料庫查詢和其他密集的伺服器端作業，那麼您選擇的託管方式就成為戰場領域的下降 TTFB 的關鍵。

選擇代管服務供應商時，請注意下列事項：

  • 您的應用程式執行個體分配了多少記憶體？如果應用程式的記憶體不足，就無法順利快速載入網頁。
  • 代管服務供應商是否讓後端堆疊為最新狀態？隨著新版應用程式後端語言、HTTP 實作項目和資料庫軟體的發布，該軟體的效能也會逐漸改善。請務必與以這類重要維護作業為優先的代管服務供應商合作。
  • 如果您有非常明確的應用程式需求，而且想取得伺服器設定檔的最低層級存取權，請詢問您自訂應用程式執行個體的後端是否合理。

市面上有許多代管服務供應商都能為您處理上述作業，但就算您在專屬的代管服務供應商中，也開始觀察到 TTFB 很長一段時間，這可能表示您可能需要重新評估目前代管服務供應商的功能，才能提供最優質的使用者體驗。

使用內容傳遞網路 (CDN)

「CDN 使用情形」主題雖然簡短，但合理原因：您的應用程式後端經過最佳化調整，但距離原始伺服器的使用者仍可能在領域遇到 TTFB 偏高的情況。

CDN 採用分散式伺服器，在離使用者較近的伺服器上快取資源，藉此解決使用者距離來源伺服器鄰近的問題。這些伺服器稱為「邊緣伺服器」。

CDN 供應商還可提供邊緣伺服器以外的優點：

  • CDN 供應商通常提供非常快的 DNS 解析時間。
  • CDN 可能會使用 HTTP/2 或 HTTP/3 等新型通訊協定，從邊緣伺服器放送您的內容。
  • HTTP/3 尤其透過使用 UDP 通訊協定來解決 TCP (HTTP/2 所依賴的) 發生 TCP/3 的頂線封鎖問題。
  • CDN 也有可能提供新型的傳輸層安全標準 (TLS) 版本，縮短 TLS 交涉時間所涉及的延遲時間。特別是 TLS 1.3 的用意是盡可能縮短 TLS 交涉時間。
  • 有些 CDN 供應商提供通常稱為「邊緣工作站」的功能，該功能使用類似於 Service Worker API 的 API 來攔截要求、透過程式管理邊緣快取中的回應，或完全重新編寫回應。
  • CDN 供應商擅長最佳化壓縮。必須自行壓縮，才能自行完成壓縮。在某些情況下，如果使用動態產生的標記，可能會導致回應速度變慢，而且必須即時壓縮。
  • CDN 供應商還會自動快取針對靜態資源壓縮的回應，以達到最佳壓縮率和回應時間組合。

採用 CDN 需要耗費大量心力，從繁瑣到重要都得差不多。因此，如果您的網站尚未使用 TTFB，建議您著手最佳化 TTFB。

盡可能使用快取內容

如果內容設有適當的 Cache-Control HTTP 標頭，CDN 可讓內容快取在離訪客較近的邊緣伺服器。雖然這不適合個人化內容，但要求一路到源頭就得徹底扭轉 CDN 的多數價值。

對於經常更新內容的網站而言，即使快取時間很短，也會讓較忙碌的網站帶來明顯的效能提升，這是因為只有第一次的訪客能在這段時間內將完全延遲時間回到原始伺服器，而其他所有訪客都可以重複使用邊緣伺服器快取的資源。部分 CDN 允許在網站版本中撤銷快取，藉此同時享有較長的快取時間，但能在需要時即時更新。

即使快取設定正確，但使用不重複查詢字串參數進行分析評估時，仍然可以忽略這個參數。這些內容雖然與 CDN 中的內容雷同，但系統不會使用快取版本。

系統也不會快取較早或較舊的內容，因此部分網頁上的 TTFB 值可能高於其他網頁。增加快取時間可以減少這個問題的影響，但請注意，快取時間增加可能會導致提供可能過時的內容。

快取內容的影響不只影響使用 CDN 的使用者。快取內容無法重複使用時，伺服器基礎架構可能需要透過昂貴的資料庫查詢作業產生內容。較常存取的資料或預先快取的網頁通常效能較佳。

避免進行多次網頁重新導向

經常導致 TTFB 的常見原因之一是重新導向。當文件的瀏覽要求收到回應，告知瀏覽器資源位於其他位置時，就會發生重新導向。一個重新導向確實可能會讓導覽要求產生不必要的延遲，但如果重新導向指向另一項資源會產生「另一個」重新導向 (以此類推)，可能會更嚴重。由於發布商基於評估目的，通常會透過分析服務重新導向，因而透過廣告或電子報獲得大量訪客的網站，這種情況特別容易受到影響。在直接控管之下減少重新導向，有助於達到良好的 TTFB。

重新導向分為兩種類型：

  • 相同來源的重新導向，也就是在網站上進行完全重新導向。
  • 跨來源重新導向，也就是先在另一個來源 (例如社交媒體網址縮短服務) 內進行重新導向，再到達您的網站。

建議你排除相同來源的重新導向，因為這是能直接控管的做法。這項作業包含檢查網站上的連結，確認是否有任何連結會產生 302 或 301 回應代碼。這通常是未包含 https:// 配置的結果 (因此瀏覽器預設為 http://，以便進行重新導向)，或是結尾的斜線並未適當納入或排除網址。

跨來源重新導向比較複雜，因為這類重新導向通常不在您的控制範圍內，但請盡量避免多次重新導向，例如在分享連結時使用多個連結縮短工具。請確認提供給廣告客戶或電子報的網址是正確的最終到達網址，以免在服務中使用的網址加入其他重新導向。

另一個重要的重新導向時間來源可能是 HTTP 到 HTTPS 重新導向。解決方法的其中一種方法是使用 Strict-Transport-Security 標頭 (HSTS)，讓瀏覽器在首次造訪來源時強制執行 HTTPS，然後指示瀏覽器在日後造訪時立即透過 HTTPS 配置存取來源。

當您擬定完善的 HSTS 政策後，即可將網站加入 HSTS 預先載入清單，以便在首次造訪來源時加快速度。

將標記串流至瀏覽器

瀏覽器在串流標記時已最佳化處理，可有效率地處理標記；也就是說，標記從伺服器收到標記時，就會分批處理。這對於大型標記酬載而言十分重要，因為這表示瀏覽器可逐步剖析標記區塊，而不是等待完整回應傳回後才能開始剖析。

雖然瀏覽器很適合用來處理串流標記，但一定要確保串流內容繼續流動，以便讓標記的初始部分盡快上線。如果後端有停滯狀態，表示一切正常。由於後端堆疊有很多種，因此本文不在本指南的涵蓋範圍內，無法涵蓋所有單一堆疊，以及各個堆疊可能出現的問題。

舉例來說，反應 (以及其他可隨選在伺服器上轉譯標記的架構) 都採用同步方法，在伺服器端進行轉譯。不過，較新版本的 React 已在算繪時實作串流標記的伺服器方法。也就是說，您不必等待 React 伺服器 API 方法轉譯完整的回應即可傳送。

如要確保標記快速串流至瀏覽器，另一種方式是採用靜態轉譯，以便在建構期間產生 HTML 檔案。備妥完整的檔案後，網路伺服器可以立即開始傳送檔案，而 HTTP 的固有性質將產生串流標記。雖然這種方法不適用於所有網站的網頁，例如必須在使用者體驗中要求動態回應的網頁，但如果網頁不需針對特定使用者量身打造標記，這種做法可能很有幫助。

使用 Service Worker

Service Worker API 對文件和資源載入資源的 TTFB 有顯著影響，原因在於服務工作處理程序是瀏覽器和伺服器之間的 Proxy，但是否對網站的 TTFB 有影響，取決於您的 Service Worker 的設定方式，以及該設定是否符合應用程式需求。

  • 使用過時即重新驗證資產的策略。如果資產位於 Service Worker 快取中 (無論是文件或文件所需的資源)，過時的重新驗證策略將「先」在背景下載該項資源，並從快取提供該資產，以供日後互動使用。
    • 如有文件資源不會經常變更，若使用過時重新驗證的策略，網頁的 TTFB 可能幾乎會立即生效。不過，如果您的網站傳送動態產生的標記 (例如會根據使用者是否經過驗證的標記變更標記)，這種做法就不適用。在這種情況下，建議您「先」連線到網路，以便盡可能提供最新的文件。
    • 如果文件載入的非重要資源隨頻率變動，但擷取過時的資源不會影響使用者體驗 (例如選取圖片或其他對不至關重要的資源)，您可以使用過時的策略大幅減少這些資源的 TTFB。
  • 針對用戶端轉譯的應用程式使用應用程式殼層模型。這個模型最適合用於從 Service Worker 快取立即傳送網頁的「殼層」，之後會在頁面生命週期中填入及轉譯網頁的動態內容。

使用 103 Early Hints 處理重要轉譯資源

無論應用程式後端的最佳化程度如何，為了準備回應，伺服器可能仍需要投入大量心力，包括相當昂貴 (目前必要) 的資料庫工作，導致導覽回應盡快送達。這種情況的潛在影響是，部分後續重要的轉譯資源 (例如 CSS) 可能會延遲；在某些情況下，JavaScript 會在用戶端轉譯標記。

103 Early Hints 標頭是早期回應代碼，當後端正忙於準備標記時，伺服器可傳送給瀏覽器。這個標頭可用來向瀏覽器提示瀏覽器在標記準備期間，應開始下載哪些轉譯資源至關重要。對於支援瀏覽器，改善文件的轉譯 (CSS) 和核心頁面功能 (JavaScript) 可用性加快。

結論

由於後端應用程式堆疊的組合有許多種，因此沒有文章可以涵蓋所有內容來降低網站的 TTFB。不過，您可以嘗試這些做法，透過伺服器端加快處理速度。

與最佳化每項指標一樣，方法基本上大同小異：在實地評估 TTFB、使用實驗室工具細查原因，然後盡可能套用最佳化設定。並不是每種技巧都適合您的情況，但某些技術或許能派上用場。一如往常，您必須密切監控現場資料，並視需要進行調整，以確保提供最快的使用者體驗。

主頁橫幅由 Taylor Vick 提供，資料來源為 Unsplash。