瞭解如何改善「第一個位元組時間」指標。
首次傳出位元組所需時間 (TTFB) 是基礎的網站效能指標，優先於其他有意義的使用者體驗指標，例如首次顯示內容所需時間 (FCP) 和最大內容繪製 (LCP)。也就是說，高 TTFB 值會增加後續指標的時間。
建議您讓伺服器快速回應導覽要求，讓75 百分位數的使用者都能在「良好」門檻值內獲得 FCP。作為粗略的參考依據，大多數網站應力求 TTFB 為 0.8 秒以下。
如何評估 TTFB
在最佳化 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 可用於評估許多應用程式後端程序，但您可能需要特別留意以下幾項：
- 資料庫查詢
- 伺服器端轉譯時間 (如適用)
- 磁碟尋找
- Edge 伺服器快取命中或未命中 (如果使用 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);
});
在實驗室中，Chrome 開發人員工具「網路」分頁的時間面板會以圖形呈現 Server-Timing 回應標頭的資料：
Server-Timing 回應標頭，在 Chrome 開發人員工具的網路分頁中以視覺化方式呈現。在此，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 配置存取來源。
設定完善的 HSTS 政策後，您可以將網站加入 HSTS 預先載入清單，加快首次造訪來源網站的速度。
將標記串流至瀏覽器
瀏覽器會在標記流式傳輸時進行最佳化，以便在標記從伺服器傳送過來時，以區塊方式處理標記。在處理大型標記酬載時，這點至關重要，因為這表示瀏覽器可以逐漸剖析標記片段，而不需要等到整個回應到達後才開始剖析。
雖然瀏覽器處理串流標記的表現相當出色，但您仍必須盡可能維持串流流量，讓初始標記盡快傳送。如果後端導致延遲，那就是問題所在。由於後端堆疊眾多，因此本指南無法涵蓋每個堆疊和各堆疊可能發生的問題。
舉例來說，React 和其他可在伺服器上按需轉譯標記的架構，都採用了同步的伺服器端轉譯方式。不過，較新的 React 版本已實作用於串流標記的伺服器方法，以便在呈現時使用。也就是說，您不必等待 React 伺服器 API 方法算出整個回應後再傳送。
另一種確保標記快速串流至瀏覽器的方式，是使用靜態算繪，在建構期間產生 HTML 檔案。由於完整檔案可立即使用，網路伺服器就能立即開始傳送檔案，而 HTTP 的固有特性會產生串流標記。雖然這種做法不一定適合每個網站的每個網頁 (例如需要動態回應的網頁)，但對於不需要標記就能為特定使用者提供個人化服務的網頁來說，這麼做可能會有所幫助。
使用服務工作者
Service Worker API 對文件和載入的資源的 TTFB 有重大影響。這是因為服務工作者會充當瀏覽器和伺服器之間的 Proxy，但這是否會影響網站的 TTFB，取決於您設定服務工作者的做法，以及該設定是否符合應用程式需求。
- 為資產使用「Stale-while-revalidate」策略。如果資產位於 Service Worker 快取中 (無論是文件或文件所需的資源)，則「過時時重新驗證」策略會優先從快取中提供該資源，然後在背景下載該資產，並在日後互動時從快取中提供該資產。
- 如果您有不常變更的文件資源，採用舊版資料重新驗證策略，可讓網頁的 TTFB 幾乎即時完成。不過，如果網站傳送的是動態產生的標記 (例如根據使用者是否完成驗證而變更的標記)，這項做法就無法正常運作。在這種情況下，您應該先連線到網路，以便取得最新的文件。
- 如果您的文件會載入不時更動的非必要資源，但擷取舊資源不會對使用者體驗造成太大影響 (例如選取圖片或其他非必要資源)，您可以採用舊資源重新驗證策略，大幅縮短這些資源的 TTFB。
- 針對由用戶端算繪的應用程式，使用應用程式殼層模型。這個模型最適合 SPA，因為 SPA 的「殼層」可從 Service Worker 快取中立即傳送，而網頁的動態內容會在網頁生命週期稍後填入並轉譯。
使用 103 Early Hints 處理轉譯關鍵資源
無論應用程式後端最佳化程度如何，伺服器仍可能需要執行大量工作才能準備回應，包括耗時 (但必要) 的資料庫工作，這會導致導覽回應無法盡快傳送。這可能會導致後續的轉譯關鍵資源延遲，例如 CSS 或在某些情況下在用戶端轉譯標記的 JavaScript。
103 Early Hints 標頭是早期回應代碼，當後端忙於準備標記時，伺服器可以將此代碼傳送至瀏覽器。這個標頭可用來提示瀏覽器，指出頁面應在標記準備期間開始下載的轉譯關鍵資源。對於支援的瀏覽器，這項功能可加快文件算繪 (CSS) 和網頁載入速度。
103 早期提示的一個缺點是，就像快取一樣，這類提示可能會掩蓋網站的「實際」TTFB。如果伺服器基礎架構速度緩慢 (可能是因為效能不足或程式碼需要最佳化)，使用 103 早期提示時，由於 TTFB 看起來很快，因此可能不明顯。使用 103 早期提示的網站應考慮評估實際的伺服器時間 (透過 PerformanceNavigationTiming API 的 Server-Timing 或 finalResponseHeadersStart)。
結論
後端應用程式堆疊的組合非常多，因此沒有一篇文章可以囊括您可以採取的所有做法，來降低網站的 TTFB。不過，您可以嘗試採用下列幾種做法，讓伺服器端的運作速度稍微加快。
如同其他指標的最佳化方式，這項指標的做法也大致相同：在實地測量 TTFB，使用實驗室工具深入瞭解原因，然後視情況套用最佳化方式。並非每種技巧都適用於您的情況，但其中有些技巧可能有效。一如往常，您需要密切留意欄位資料，並視需要調整，確保使用者能盡可能享有最快速的體驗。
主頁橫幅圖片由 Taylor Vick 提供，來源為 Unsplash。