如要建構載入速度飛快的網站，第一步是確保伺服器能及時回應網頁的 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。
如要謹慎處理 HTML 快取，可以使用 ETag 或 Last-Modified 回應標頭。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 相關的效能考量，可以更輕鬆地確保網站盡快載入，但這只是學習網頁效能的開端。接下來，我們將說明重要彩現路徑背後的理論。本單元會說明重要概念，例如會阻礙算繪和剖析的資源，以及這些資源在瀏覽器中盡快完成網頁初始算繪時扮演的角色。