瞭解如何最佳化 Time to First Byte 指標。
發布日期：2023 年 1 月 19 日，上次更新日期：2025 年 11 月 28 日
Time to First Byte (TTFB) 是基礎網站成效指標，優先於所有其他有意義的使用者體驗指標，例如 First Contentful Paint (FCP) 和 Largest Contentful Paint (LCP)。也就是說，TTFB 值偏高會增加後續指標的時間。
建議您讓伺服器能快速回應導覽要求，讓 75% 的使用者體驗到「良好」門檻內的 FCP。一般來說，大多數網站應盡可能將 TTFB 縮短至 0.8 秒以下。
如何評估 TTFB
最佳化 TTFB 前，請先觀察這項指標對網站使用者的影響。您應以欄位資料做為觀察 TTFB 的主要來源，因為 TTFB 會受到重新導向影響，而實驗室工具通常會使用最終網址進行評估，因此會遺漏這項額外延遲。
PageSpeed Insights 是取得公開網站現場和實驗室資訊的方法之一，這些資訊可在 Chrome 使用者體驗報告中取得。
實際使用者的 TTFB 會顯示在頂端的「瞭解實際使用者的體驗」部分：
如果是實驗室資料，TTFB 問題會顯示在「文件要求延遲」洞察中：
如要進一步瞭解如何在現場和實驗室中評估 TTFB，請參閱 TTFB 指標頁面。
瞭解實際和實驗室 TTFB 的差異
實驗室和實際 TTFB 可能因多種原因而有所不同，如果兩者不同，請務必瞭解原因，才能有效運用實驗室資料改善使用者體驗。
如果實驗室 TTFB 遠大於實際 TTFB，表示實驗室環境比一般使用者體驗更受限。這不一定是問題，因為實驗室結果和建議仍有效，但可能會誇大影響和改善效果。
如果實際 TTFB 遠大於實驗室 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 - $dbReadStartTime) / 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」分頁的「Timings」面板中：
在這裡，Server-Timing 是用來衡量資源要求是否命中 CDN 快取，以及要求命中 CDN 邊緣伺服器，然後命中來源所需的時間。
伺服器時間也會顯示在 Chrome 開發人員工具「Performance」面板的「Network」軌跡中：
分析可用資料後，如果確定 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，則應優先考慮採用 CDN，以最佳化 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 已實作伺服器方法，可在轉譯時串流標記。也就是說，您不必等待 React 伺服器 API 方法轉譯整個回應，再傳送回應。
另一種確保標記快速串流至瀏覽器的方法，是依賴靜態轉譯，在建構期間產生 HTML 檔案。由於完整檔案立即可用，網路伺服器可以立即開始傳送檔案，而 HTTP 的固有性質會導致串流標記。雖然這種做法不適用於每個網站的每個網頁 (例如需要動態回應做為使用者體驗一部分的網頁)，但對於不需要針對特定使用者提供個人化標記的網頁，這種做法可能很有幫助。
使用 Service Worker
Service Worker API 對文件和載入資源的 TTFB 有重大影響。這是因為 Service Worker 會在瀏覽器和伺服器之間扮演 Proxy 的角色，但網站的 TTFB 是否會受到影響，取決於您設定 Service Worker 的方式，以及該設定是否符合應用程式需求。
- 對資產使用stale-while-revalidate 策略。如果資產位於 Service Worker 快取中 (無論是文件或文件所需的資源)，stale-while-revalidate 策略會「先」從快取提供該資源，然後在背景下載該資產，並從快取提供該資產，以便日後互動。
- 如果文件資源不常變更，使用 stale-while-revalidate 策略可讓網頁的 TTFB 幾乎即時。不過，如果網站傳送動態產生的標記 (例如根據使用者是否通過驗證而變更的標記)，這種做法的效果就不太好。在這種情況下，您一律會想「先」連上網路，確保文件盡可能保持最新狀態。
- 如果文件載入的非關鍵資源會不時變更，但擷取過時資源不會大幅影響使用者體驗 (例如選取圖片或其他非關鍵資源)，則可使用 stale-while-revalidate 策略，大幅降低這些資源的 TTFB。
- 針對用戶端轉譯的應用程式，使用應用程式命令介面模型。這個模型最適合用於單頁應用程式，因為網頁的「殼層」可以立即從 Service Worker 快取傳送，而網頁的動態內容則會在網頁生命週期的稍後階段填入及算繪。
對轉譯關鍵資源使用 103 Early Hints
無論應用程式後端經過多完善的最佳化，伺服器仍可能需要執行大量工作才能準備回應，包括耗費大量資源 (但必要) 的資料庫工作，導致導覽回應無法盡快送達。這可能會導致部分後續轉譯關鍵資源延遲，例如 CSS 或 (在某些情況下) 在用戶端轉譯標記的 JavaScript。
103 Early Hints 標頭是伺服器在後端忙於準備標記時，可傳送至瀏覽器的早期回應代碼。這個標頭可用來提示瀏覽器，在準備標記時，網頁應開始下載轉譯關鍵資源。在支援的瀏覽器中，這項功能可加快文件轉譯 (CSS) 和載入網頁的速度。
103 Early Hints 的缺點之一是，就像快取一樣，可能會遮蓋網站的「實際」TTFB。如果伺服器基礎架構速度緩慢 (可能是因為效能不足或程式碼需要最佳化)，則使用 103 Early Hints 時，由於 TTFB 速度很快，因此可能較不明顯。使用 103 Early Hints 的網站應考慮評估實際伺服器時間 (透過 PerformanceNavigationTiming API 的 Server-Timing 或 finalResponseHeadersStart)。
結論
後端應用程式堆疊的組合非常多，因此沒有任何一篇文章能涵蓋所有可降低網站 TTFB 的做法。不過，您可以嘗試以下幾種方法，加快伺服器端的處理速度。
與最佳化所有指標一樣，方法大致相同：在現場評估 TTFB、使用實驗室工具深入探討原因，然後盡可能套用最佳化。雖然有些技術可能不適用於您的情況，但有些可能適用。一如往常，請務必密切留意現場資料，並視需要進行調整，確保使用者能享有最快的體驗。