想建置載入速度快的網站，第一步就是取得
表示伺服器對網頁 HTML 的回應。如果在
瀏覽器網址列，瀏覽器會將 GET 要求傳送至伺服器，
擷取。網頁的第一個要求是針對 HTML 資源，
確保 HTML 快速送達且盡量減少延遲，是主要成效
目標。
這項 HTML 初始要求會經過數個步驟，每個步驟都會 一些時間。減少每個步驟花費的時間，您就能更快 First Byte (TTFB)。雖然 TTFB 並非唯一應該關注的重點指標 由於網頁載入速度相當快，TTFB 偏高 指定為「良好」Largest Contentful Paint 指標的閾值 (LCP) 和《First Contentful Paint (FCP)》。
將重新導向次數降到最低
要求資源時，伺服器可能會以重新導向的形式回應，
含有永久重新導向 (301 Moved Permanently 回應) 或使用暫時性重新導向
一 (302 Found 回應)。
重新導向會導致網頁載入速度變慢，因為瀏覽器必須 新位置的額外 HTTP 要求來擷取資源。另有 兩種重新導向類型：
- 同源重新導向，完全在來源內發生。這些類型 完全由您掌控，因為管理邏輯 這些指令會完全位於您的網路伺服器中。
- 由其他來源啟動的跨來源重新導向。這些類型的 重新導向通常無法控制，
跨來源重新導向通常用於廣告、短網址服務等 獲得設定、配置和疑難排解相關協助雖然跨來源重新導向不在您的控制範圍內， 您可能還是要檢查是否避免多次重新導向，例如 讓廣告連結至 HTTP 網頁，然後該網頁會重新導向到其 HTTPS 或是跨來源重新導向，而且到達您的來源，但 觸發同源重新導向。
快取 HTML 回應
快取 HTML 回應並不容易，因為回應中可能包含 其他重要資源，例如 CSS、JavaScript、圖片和其他資源 。這些資源各自包含專屬指紋 檔案名稱，系統會根據檔案內容變更檔案名稱。這表示 HTML 文件在部署之後可能會過時，因為其中包含 參照過時子資源
儘管如此，短的快取生命週期 (不只是沒有快取) 也能帶來好處 例如允許在 CDN 快取資源，藉此減少 透過來源伺服器提供給您的要求， 重新驗證資源而非重新下載。這個方法可以 適合沒有任何情境變動的靜態內容 快取資源的時間可設為您給予的分鐘數 或適當。5 分鐘提供靜態 HTML 資源是安全可靠的做法， 而且不會注意到定期更新
如果網頁的 HTML 內容以某種方式個人化 (例如 ，您很有可能完全不希望快取內容 安全問題 和更新間隔如果 HTML 回應 就無法將快取失效。是 因此在這類情況下，建議您完全避免快取 HTML。
快取 HTML 時非常謹慎，可以使用 ETag 或
Last-Modified 回應標頭。ETag，也稱為實體
標記—標題是專門用來代表要求資源的識別碼。
，且通常會使用資源內容的雜湊：
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
每當資源變更時，都必須產生新的 ETag 值。啟用
後續要求則瀏覽器會透過 ETag
If-None-Match 要求標頭。伺服器上的 ETag 與
就會傳回 304 Not Modified 回應
瀏覽器也會使用快取的資源雖然這種狀況
網路延遲，304 Not Modified 回應的大小遠小於整個
HTML 資源。
然而，重新驗證資源更新間隔所涉及的網路延遲 但仍有點困難如同網頁開發的許多其他層面 不論如何，每次都得取捨這完全由您決定 值得您額外努力以這種方式快取 HTML，或者您也可以選擇 應能放心使用，完全不需煩惱快取 HTML 內容。
測量伺服器回應時間
如果未快取回應，伺服器的回應時間會很久，取決於 主機供應商和後端應用程式堆疊主要用來放送 動態產生的回應 (例如從資料庫擷取資料) 那麼，TFB 的 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 布洛特利。與 gzip 相比，Brotli 大約提升 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 程式碼就大功告成了，那麼為了確保網頁能夠載入 但這只是學習網路的第一步 才需進行接下來，「關鍵轉譯路徑」的理論是 課程。本單元會說明會妨礙顯示 需要剖析資源，以及這些資源在取得網頁 在瀏覽器中快速顯示內容