瞭解如何改善「第一個位元組時間」指標。
首次傳送位元組所需時間 (TTFB) 是基礎網站效能指標，優先於其他有意義的使用者體驗指標，例如首次顯示內容所需時間 (FCP) 和最大內容繪製 (LCP)。也就是說，高 TTFB 值會增加後續指標的時間。
建議您讓伺服器快速回應導覽要求，讓75 百分位數的使用者都能在「良好」門檻值內獲得 FCP。作為粗略的參考依據，大多數網站應力求 TTFB 為 0.8 秒以下。
如何評估 TTFB
在最佳化 TTFB 之前，您需要觀察 TTFB 對網站使用者造成的影響。您應以實地資料做為觀察 TTFB 的主要來源，因為 TTFB 會受到重新導向影響，而實驗室工具通常會使用最終網址進行評估，因此不會偵測到這項額外延遲時間。
PageSpeed Insights 可讓您取得公開網站的現場和實驗室資訊，這些資訊可在 Chrome 使用者體驗報告中找到。
實際使用者的 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 通訊協定，解決了 HTTP/2 所依賴的 TCP 中存在的首行封鎖問題。
- 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 快取中 (無論是文件或文件所需的資源)，則「過時時重新驗證」策略會優先從快取中提供該資源，然後在背景下載該資產，並在日後互動時從快取中提供該資產。
- 如果您有較不常變更的文件資源，採用「Stale-while-revalidate」策略可讓網頁的 TTFB 幾乎即時。不過，如果網站傳送的是動態產生的標記 (例如根據使用者是否完成驗證而變更的標記)，這項做法就無法正常運作。在這種情況下，您應該先連線到網路，以便取得最新的文件。
- 如果您的文件會載入會經常變更的非必要資源，但擷取陳舊資源不會對使用者體驗造成太大影響 (例如選取圖片或其他非必要資源)，則可以使用陳舊資源重新驗證策略，大幅縮短這些資源的 TTFB。
- 針對由用戶端算繪的應用程式使用應用程式殼模型。這個模型最適合 SPA，因為 SPA 的「殼層」可從 Service Worker 快取中立即傳送，而網頁的動態內容會在網頁生命週期稍後填入並轉譯。
使用 103 Early Hints 處理轉譯關鍵資源
無論應用程式後端最佳化程度如何，伺服器仍可能需要執行大量工作才能準備回應，包括耗時 (但必要) 的資料庫工作，這會導致導覽回應無法盡快傳送。這可能會導致後續的轉譯關鍵資源延遲，例如 CSS 或在某些情況下在用戶端轉譯標記的 JavaScript。
103 Early Hints 標頭是早期回應代碼，可在後端忙於準備標記時，由伺服器傳送至瀏覽器。這個標頭可用來提示瀏覽器，指出頁面應在標記準備期間開始下載的轉譯關鍵資源。對於支援的瀏覽器，這項功能可加快文件轉譯作業 (CSS)，並加快提供核心網頁功能 (JavaScript)。
結論
後端應用程式堆疊的組合非常多，因此沒有一篇文章可以囊括您可以採取的所有做法，來降低網站的 TTFB。不過，您可以嘗試採用下列幾種做法，讓伺服器端的運作速度稍微加快。
如同其他指標的最佳化方式，這項指標的做法也大致相同：在實地測量 TTFB，使用實驗室工具深入瞭解原因，然後視情況套用最佳化方式。並非每種技巧都適用於您的情況，但其中有些技巧可能有效。一如往常，您需要密切留意欄位資料，並視需要調整，確保使用者能盡可能享有最快速的體驗。
主頁橫幅圖片由 Taylor Vick 提供，來源為 Unsplash。