最佳化首次位元組的時間

瞭解如何最佳化「第一個位元組時間」指標。

Jeremy Wagner
Barry Pollard

第一個位元組時間 (TTFB) 是其他所有有意義的使用者體驗指標 (例如首次顯示內容所需時間 (FCP) 和最大內容繪製 (LCP)) 的基本網站成效指標。這表示 TTFB 值較高，在後續的指標中增加時間。

建議您讓伺服器能快速回應導航要求，讓 75 個百分位數的使用者在「良好」門檻內體驗 FCP。大部分網站都應盡力將 TTFB 不超過 0.8 秒。

良好 TTFB 值的長度在 0.8 秒內，不佳的值超過 1.8 秒，而且需要改善

如何評估 TTFB

將 TTFB 最佳化之前，您需要先觀察 TTFB 對網站使用者的影響。您應仰賴「欄位資料」做為觀察 TTFB 的主要來源，因為資料會受到重新導向的影響；研究室型工具通常是用最終到達網址進行評估，因此會缺少這項額外延遲。

如要取得公開網站的欄位和研究室資訊，建議您透過 Chrome 使用者體驗報告，運用 PageSpeed Insights 輕鬆取得所需資訊。

實際使用者的 TTFB 會顯示在「探索實際使用者體驗」部分：

PageSpeed Insights 實際使用者資料

伺服器回應時間稽核中會顯示部分 TTFB 的資料：

伺服器回應時間稽核

如需有關在實際領域和研究室中評估 TTFB 的其他方法，請參考「TTP 指標」頁面。

透過 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 開發人員工具「網路」分頁的時間面板中：

Chrome 開發人員工具「網路」分頁的 Server-Timing 標頭值示意圖。在這張圖片中，「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 仰賴) 中的前線封鎖問題。
  • CDN 可能也會提供新型傳輸層安全標準 (TLS)，縮短傳輸層安全標準 (TLS) 交涉時間的延遲時間。TLS 1.3 特別是為了縮短 TLS 協商而設計。
  • 部分 CDN 供應商提供一項功能通常稱為「邊緣工作站」，這個功能會使用與 Service Worker API 類似的 API 來攔截要求、以程式輔助方式在邊緣快取中管理回應，或是重新編寫回應。
  • CDN 供應商擅長將壓縮功能最佳化，自行壓縮並不容易，在某些情況下，由於動態產生的標記必須即時壓縮，因此回應速度會變慢。
  • CDN 供應商也會自動快取靜態資源的壓縮回應，讓壓縮比率與回應時間達到最佳組合。

雖然採用 CDN 需要付出的心力不及重大，但若您的網站尚未使用 CDN，應優先追求改善 TTFB。

盡可能使用快取內容

CDN 可讓內容快取至距離訪客最近的邊緣伺服器，只要內容是以適當的 Cache-Control HTTP 標頭設定即可。雖然這並不適用於個人化內容，但要求一路往回起點可能會否定 CDN 的大部分值。

如果網站經常更新內容，即使快取時間短，也可能導致忙碌的網站效能明顯提升，因為這段時間只有第一位訪客會使原始伺服器完全延遲，而其他訪客都可以重複使用邊緣伺服器中的快取資源。部分 CDN 允許在網站發布版本進行快取撤銷作業，讓您無論身在何處都能享有最佳體驗，例如延長快取時間，還能在需要時即時更新。

即使已正確設定快取，如果使用不重複的查詢字串參數進行分析評估，就可以忽略這項設定。雖然這兩個廣告素材的內容與 CDN 的內容相同，但兩者的內容可能不同，因此不會使用快取版本。

系統也可能未快取較舊或較少造訪的內容，這可能會導致某些網頁的 TTFB 值高於其他值。增加快取時間可減少這個問題的影響，但請注意，如果延長快取時間，較有可能提供可能過時的內容。

快取內容的影響不僅會影響使用 CDN 的內容，如果無法重複使用快取的內容，伺服器基礎架構可能需要透過昂貴的資料庫查詢產生內容。一般來說，存取頻率較高的資料或預先快取網頁的效能通常較佳。

避免多次網頁重新導向

重新導向是高 TTFB 的常見貢獻者。當文件的導覽要求收到回應，告知瀏覽器資源存在於其他位置時，就會進行重新導向。有些重新導向很可能會對導覽要求造成不必要的延遲，但要是重新導向至另一個產生「另一個」重新導向的資源，情況勢必會更糟。這尤其可能影響到透過廣告或電子報獲得大量訪客的網站，因為這類網站通常會透過分析服務進行評估。在直接控制下減少重新導向有助於達到良好的 TTFB。

重新導向有兩種類型：

  • 同來源重新導向，重新導向完全發生在您的網站。
  • 跨來源重新導向：最初是從另一個來源 (例如社交媒體網址縮短服務) 進行重新導向，再到達你的網站。

建議您著重於排除相同來源的重新導向，因為這是可直接控制的。這項作業包括檢查網站上的連結，確認是否有任何連結會產生 302 或 301 回應代碼。通常這通常是沒有加入 https:// 配置 (因此瀏覽器預設會重新導向 http://，接著會重新導向) 的原因，或是網址結尾的斜線未正確納入或排除。

跨來源重新導向較難，因為這類重新導向通常不在您的控制範圍內，但請盡可能避免多次重新導向，例如在分享連結時使用多個連結縮短器。請確保提供給廣告客戶或電子報的網址是正確的最終到達網址，避免將廣告重新導向到其他服務所使用的網址。

另一個重要的重新導向時間可能來自 HTTP 到 HTTPS 重新導向。舉例來說，您可以使用 Strict-Transport-Security 標頭 (HSTS)，在第一次造訪來源時強制執行 HTTPS，然後通知瀏覽器日後造訪時，立即透過 HTTPS 配置存取來源。

設定完善的 HTTP 嚴格傳輸安全性政策後，只要將網站加入 HSTS 預先載入清單，即可加快首次造訪來源的速度。

將標記串流至瀏覽器

瀏覽器已經過最佳化，可以在串流時有效處理標記，也就是說，標記從伺服器收到時，會依區塊分段處理。如果標記承載非常不容易，就十分重要，因為這意味著瀏覽器可以逐步剖析標記區塊，而不是等待整個回應在剖析開始之前才產生。

雖然瀏覽器很擅長處理串流標記，但請務必這麼做，確保串流內容能持續進行，以便盡快導入這類標記。如果後端保持運作狀態，就會發生問題。由於後端堆疊不計其數，因此會比本指南的範圍不涵蓋每個堆疊，以及每個特定堆疊中可能出現的問題。

舉例來說，以及其他可以在伺服器上轉譯標記的架構，都已採用同步方法來進行伺服器端轉譯。不過，新版 React 在轉譯時導入了串流標記的伺服器方法。也就是說，您不必等待 React 伺服器 API 方法顯示完整回應，就能在送出回應時傳送。

另一個確保標記能夠快速串流至瀏覽器的方法，就是透過靜態轉譯，在建構期間產生 HTML 檔案。取得完整檔案後，網路伺服器就能立即開始傳送檔案，HTTP 本身的特性將會產生串流標記。雖然這種做法不適用於每個網站上的每個網頁 (例如需要動態回應做為使用者體驗的一部分)，因此對於不需要為特定使用者進行個人化標記的網頁，這項功能就很實用。

使用 Service Worker

Service Worker API 可能會對 TTFB 造成重大影響，對於文件及其載入的資源都有影響。這是因為服務工作處理程序就像是瀏覽器和伺服器之間的 Proxy，但是是否對網站的 TTFB 產生影響，取決於您如何設定服務工作處理程序，以及設定是否符合應用程式需求。

  • 為素材資源使用過時的重新驗證策略。如果資產儲存在 Service Worker 快取中 (例如文件或文件所需的資源)，過時/重新驗證的策略就會「先」從快取處理該資源，接著就會在背景下載資產，並從快取提供該資產，以供日後互動使用。
    • 如果您有不會經常變更的文件資源，使用過時的重新驗證策略可能會讓網頁的 TTFB 幾乎立即生效。不過，如果您的網站會傳送動態產生的標記 (例如，系統會根據使用者是否已通過驗證來變更標記)，這個方法並不有效。這樣的話，您永遠都希望「優先」連上網路，這樣文件才會越即時越好。
    • 如果您的文件載入一般資源且頻率會變動，但擷取過時資源不會對使用者體驗造成極大影響，例如選取過時的圖片或其他不重要的資源，那麼使用過時重新驗證的策略，即可大幅減少這些資源的 TTFB。
  • 盡可能使用串流服務工作站架構。這個 Service Worker 架構使用的方法會將文件資源的部分內容儲存在 Service Worker 快取中，並在導覽要求期間與內容部分合併。使用這個 Service Worker 模式所產生的影響，是能夠加快瀏覽速度，而較小的 HTML 酬載則是從網路下載。雖然此服務工作模式模式並不適用於所有網站，但是文件資源的 TTFB 時間可實際立即用於網站。
  • 針對用戶端轉譯應用程式使用應用程式殼層模型。此模型最適合用於「SPA」，也就是網頁的「殼層」可從 Service Worker 快取傳送，且網頁的動態內容會在之後的頁面生命週期中填入及轉譯。

針對會轉譯重要資源使用 103 Early Hints

無論應用程式後端的最佳化程度有多高，伺服器仍需要執行大量工作來準備回應，包括昂貴 (但當下) 的資料庫工作，導致導覽回應以最快的速度抵達。這可能造成的影響，在於部分後續的轉譯重要資源 (例如 CSS) 或在某些情況下 (在某些情況下是會在用戶端轉譯標記的 JavaScript) 可能會延遲。

103 Early Hints 標頭是早期回應代碼，後端可在後端忙於準備標記時，傳送至瀏覽器。系統可透過這個標頭，向瀏覽器提示網頁在標記準備期間應開始下載哪些有重要轉譯資源。對支援瀏覽器而言，效果可加快文件轉譯 (CSS) 的速度，並更快呈現核心網頁功能 (JavaScript)。

結論

由於後端應用程式堆疊的組合眾多，因此沒有一篇文章能夠封裝「一切」來降低網站的 TTFB。不過，您可以運用這些選項，稍微提升伺服器端作業的處理速度。

與最佳化每項指標時，做法很類似：評估實際領域的 TTFB、使用研究室工具深入瞭解原因，然後盡可能套用最佳化措施。並非每種方法都可能符合您的情況，但有些技術仍然可能。您必須像往常一樣密切留意欄位資料，並視需要進行調整，才能確保提供最快速的使用者體驗。

主頁橫幅來源：Taylor Vick，來源為 Unsplash。