要建構能快速載入的網站，第一步是接收伺服器針對網頁 HTML 的即時回應。在瀏覽器的網址列中輸入網址時，瀏覽器會將 GET 要求傳送至伺服器進行擷取。第一個網頁要求是針對 HTML 資源，而確保 HTML 能在最短延遲時間內快速送達，就是主要的效能目標。
初次要求 HTML 時，需要經過幾個步驟，每個要求都需花費一些時間。減少每個步驟花費的時間，可加快第一個位元組 (TTFB)。雖然 TTFB 不是網頁載入速度的唯一指標，但 TTFB「確實」較難達到針對最大內容繪製 (LCP) 和首次顯示內容所需時間 (FCP) 等指標，很難達到指定的「良好」門檻。
盡量減少重新導向次數
要求資源時，伺服器可能會以永久重新導向 (301 Moved Permanently 回應) 或臨時重新導向 (302 Found 回應) 回應。
重新導向會使網頁載入速度變慢，因為瀏覽器必須在新位置發出額外的 HTTP 要求，才能擷取資源。重新導向分為兩種類型：
- 完全在來源中進行的相同來源重新導向。這些類型的重新導向完全位於您的網路伺服器中，因此這些類型的重新導向完全由您掌控。
- 由其他來源發起的跨來源重新導向。這類重新導向通常不在您的掌控範圍內。
廣告、短網址服務和其他第三方服務通常會使用跨來源重新導向。雖然跨來源重新導向不在您的控制範圍內，但仍建議您檢查並確認是否避免多次重新導向，例如廣告連結到 HTTP 網頁，導致重新導向至對等的 HTTPS 網頁；或是跨來源重新導向會抵達您的來源，然後觸發相同的來源重新導向。
快取 HTML 回應
快取 HTML 回應非常困難，因為回應可能會包含其他重要資源 (例如 CSS、JavaScript、圖片和其他資源類型) 的連結。這些資源可能在各自的檔案名稱中加入不重複的指紋，而這個指紋會根據檔案內容而改變。這表示快取 HTML 文件在部署後可能會過時，因為其中包含過時子資源的參照。
儘管如此，在快取生命週期較短 (而非無快取) 的情況下，都有以下優點：在 CDN 中快取資源，減少從原始伺服器提供的要求數量，以及在瀏覽器中允許重新驗證資源，而非重新下載。此方法最適合不會在任何情境中變動的靜態內容使用。對於資源的適當快取時間，可以設定為適當的分鐘數。請妥善使用靜態 HTML 資源五分鐘，並確保定期更新不被注意到。
如果網頁的 HTML 內容是透過某種方式 (例如經過驗證的使用者) 使用，那麼您就非常不想為了安全和更新等各種疑慮而快取內容。如果使用者的瀏覽器快取了 HTML 回應，您就無法撤銷快取。在這種情況下，最好避免完全快取 HTML。
建議您使用 ETag 或 Last-Modified 回應標頭來快取 HTML。ETag (也稱為實體標記) 標頭是專門用來代表要求資源的 ID，通常使用資源內容的雜湊：
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
每當資源變更，就必須產生新的 ETag 值。後續要求時，瀏覽器會透過 If-None-Match 要求標頭傳送 ETag 值。如果伺服器上的 ETag 與瀏覽器傳送的值相符，伺服器就會回應 304 Not Modified 回應，而瀏覽器會使用快取中的資源。雖然這麼做仍會產生網路延遲，但 304 Not Modified 回應「明顯」小於整個 HTML 資源。
然而，重新驗證資源更新間隔時所涉及的網路延遲仍然存在差異。與網頁開發的其他許多層面一樣， 破壞和入侵是無法避免的。您有必要瞭解以這種方式快取 HTML 是否值得這麼做，或是最好在安全端保持運作，不要阻礙 HTML 內容快取。
測量伺服器回應時間
如果未快取回應，伺服器的回應時間會因為主機供應商和後端應用程式堆疊而有極大影響。提供動態產生回應的網頁 (例如從資料庫擷取資料) 的 TTFB 可能遠高於可以立即提供的靜態網頁，而不需在後端投入大量運算時間就能立即取得。如果顯示載入旋轉圖示，然後在用戶端擷取所有資料，便將工作從較容易預測的伺服器端環境移至可能難以預測的用戶端端。盡量減少用戶端的負擔，通常能改善以使用者為中心的指標。
如果使用者在欄位碰到速度緩慢的 TTFB，您可以使用 Server-Timing 回應標頭公開在伺服器上的時間使用資訊：
Server-Timing: auth;dur=55.5, db;dur=220
Server-Timing 標頭的值可包含多個指標，以及每個指標的時間長度。然後，您就可以從使用 Navigation Timing API 的現場使用者收集這項資料，並進行分析，瞭解使用者是否遇到延遲。在上述程式碼片段中，回應標頭包含兩個時間：
- 驗證使用者 (
auth) 所需的時間，耗時 55.5 毫秒。 - 資料庫存取時間 (
db)，耗時 220 毫秒。
建議您一併查看代管基礎架構，並確認擁有充足的資源能處理網站獲得的流量。共用主機供應商通常容易受到高 TTFB 的困擾，而在縮短回應時間的專屬解決方案中，成本可能較高。
壓縮
文字回應 (例如 HTML、JavaScript、CSS 和 SVG 圖片) 應壓縮，來縮減網路傳輸大小，才能加快下載速度。gzip 和 Brotli 是最常用的壓縮演算法。Brotli 與 gzip 相較大約提高了 15% 到 20%。
大多數網站主機供應商通常會自動設定壓縮功能，但如果您正在自行調整或調整壓縮設定，請務必考量以下幾點：
- 盡可能使用 Brotli。如先前所述，Brotli 在使用 gzip 時提供了相當明顯的改善，而 Brotli 適用於所有主要瀏覽器。請盡可能使用 Brotli，但如果舊版瀏覽器有大量使用者使用您的網站，請務必將 gzip 當做備用方案，因為任何壓縮都比沒有壓縮來得好。
- 檔案大小很重要。資源極小 (小於 1 KiB) 無法妥善壓縮，或者甚至根本不會壓縮。不論資料壓縮類型是否有效，還是取決於壓縮演算法可使用的大量資料，以找出更多可壓縮的資料位元。檔案越大，壓縮效果就越好。不過，如果提供資源較不大，壓縮效果就比較好。例如 JavaScript 和 CSS 等大型資源在瀏覽器解壓縮後，需要花費大量時間來剖析和評估，而且即使只有邊邊變更，變更頻率也會更高，因為任何變更都會產生不同的檔案雜湊。
- 瞭解動態與靜態壓縮。動態和靜態壓縮對於「何時」應壓縮資源會採用不同的方法。動態壓縮功能會在「收到資源時」壓縮資源，有時也會在要求「每次」要求時壓縮。另一方面，靜態壓縮會提前壓縮檔案，因此在要求期間不進行壓縮。靜態壓縮可消除壓縮本身所涉及的延遲，在動態壓縮的情況下可能增加伺服器回應時間。靜態資源 (例如 JavaScript、CSS 和 SVG 圖片) 應進行靜態壓縮，而 HTML 資源則更應為經驗證的使用者動態產生，因此請採用動態壓縮方式。
自行壓縮檔案並不容易，通常最好讓內容傳遞網路 (CDN) 為您處理這項作業 (詳情請參閱下一節的說明)。不過，瞭解這些概念可協助您辨識主機供應商是否正常使用壓縮功能。您可根據所學知識，找出改善壓縮設定的機會，進而為網站帶來最大效益。
內容傳遞網路 (CDN)
「內容傳遞網路 (CDN)」是伺服器的分散式網路，會從原始伺服器快取資源，並從較靠近使用者的邊緣伺服器提供資源。與使用者的實際距離可縮短往返時間 (RTT)，而 HTTP/2 或 HTTP/3、快取和壓縮等最佳化功能，則可讓 CDN 提供內容的速度比從原始伺服器擷取更快。在某些情況下，使用 CDN 可以大幅改善網站的 TTFB。
學以致用
哪種重新導向完全由您掌控？
Server-Timing 標頭可包含多個指標。
哪種類型的伺服器最接近您的使用者？
下一步：瞭解關鍵路徑
現在，您已瞭解與網站 HTML 互動的相關效能問題，就可以進一步確保網頁載入速度更快了，但這只是瞭解網頁效能的起點。接下來，我們將介紹關鍵轉譯路徑背後的理論。本模組說明會阻擋轉譯和剖析封鎖資源等重要概念，以及這些概念在瀏覽器內盡快進行頁面初始轉譯所扮演的角色。