最佳化首次位元組的時間

瞭解如何改善「第一個位元組時間」指標。

首次傳送位元組所需時間 (TTFB) 是基礎的網站效能指標,優先於其他有意義的使用者體驗指標,例如首次顯示內容所需時間 (FCP)最大內容繪製 (LCP)。也就是說,高 TTFB 值會增加後續指標的時間。

建議您讓伺服器快速回應導覽要求,讓75 百分位數的使用者都能在「良好」門檻值內獲得 FCP。作為粗略的參考依據,大多數網站應力求 TTFB 為 0.8 秒以下

良好的 TTFB 值為 0.8 秒以下,不良的值為 1.8 秒以上,介於兩者之間的值則需要改善

如何評估 TTFB

在最佳化 TTFB 之前,您需要觀察 TTFB 對網站使用者的影響。您應以實地資料做為觀察 TTFB 的主要來源,因為 TTFB 會受到重新導向影響,而實驗室工具通常會使用最終網址進行評估,因此不會偵測到這項額外延遲時間。

PageSpeed Insights 可讓您取得公開網站的現場和實驗室資訊,這些資訊可在 Chrome 使用者體驗報告中找到。

實際使用者的 TTFB 會顯示在頂端的「瞭解實際使用者體驗」部分:

PageSpeed Insights 實際使用者資料,包括 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 回應標頭的資料:

Chrome 開發人員工具「網路」分頁中,以視覺化方式呈現伺服器時間標頭值。在這個圖片中,Server-Timing 標頭值會評估 CDN 邊緣伺服器是否遇到快取命中或未命中,以及從邊緣和原始伺服器擷取資源所需的時間。

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。

轉送有兩種類型:

  • 同源重新導向,也就是在您網站上完全發生重新導向的情況。
  • 跨來源重新導向:重新導向一開始發生在其他來源 (例如社群媒體網址縮短服務),然後才到達您的網站。

您應專注於移除相同來源的重新導向,因為這是您可以直接控管的部分。這包括檢查網站上的連結,看看是否有任何連結會導致 302301 回應代碼。這通常是因為未納入 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,因為在這種情況下,網頁的「殼層」可以從 Service Worker 快取中立即傳送,而網頁的動態內容會在網頁生命週期後期填入並轉譯。

使用 103 Early Hints 處理轉譯關鍵資源

無論應用程式後端的最佳化程度如何,伺服器仍可能需要執行大量工作才能準備回應,其中包括耗時 (但必要) 的資料庫工作,會導致導覽回應無法盡快傳送。這可能會導致後續的轉譯關鍵資源延遲,例如 CSS 或在某些情況下在用戶端轉譯標記的 JavaScript。

103 Early Hints 標頭是早期回應代碼,可在後端忙於準備標記時,由伺服器傳送至瀏覽器。這個標頭可用來提示瀏覽器,指出頁面應在標記準備期間開始下載的轉譯關鍵資源。對於支援的瀏覽器,這項功能可加快文件轉譯作業 (CSS),並加快提供核心網頁功能 (JavaScript)。

結論

後端應用程式堆疊的組合非常多,因此沒有一篇文章可以囊括您可以採取的所有做法,來降低網站的 TTFB。不過,您可以嘗試採用下列幾種做法,讓伺服器端的運作速度稍微加快。

如同其他指標的最佳化方式,這項指標的做法也大致相同:在實地測量 TTFB,使用實驗室工具深入瞭解原因,然後視情況套用最佳化方式。並非每項技巧都適用於您的情況,但其中有些技巧可能有效。一如往常,您需要密切留意欄位資料,並視需要調整,確保使用者能盡可能享有最快速的體驗。

主頁橫幅圖片由 Taylor Vick 提供,來源為 Unsplash。