瞭解如何改善「第一個位元組時間」指標。
首次傳送位元組所需時間 (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。