前端性能 2021：網絡、HTTP/2、HTTP/3

已發表: 2022-03-10
快速總結↬讓2021年……快點！ 一份年度前端性能清單，包含您在當今 Web 上創建快速體驗所需了解的所有內容，從指標到工具和前端技術。 自 2016 年以來更新。

目錄

  1. 準備：計劃和指標
  2. 設定切合實際的目標
  3. 定義環境
  4. 資產優化
  5. 構建優化
  6. 交付優化
  7. 網絡、HTTP/2、HTTP/3
  8. 測試和監控
  9. 快速獲勝
  10. 一切都在一頁上
  11. 下載清單（PDF、Apple Pages、MS Word）
  12. 訂閱我們的電子郵件通訊不要錯過下一個指南。

網絡、HTTP/2、HTTP/3

  1. 是否啟用了 OCSP 裝訂？
    通過在您的服務器上啟用 OCSP 裝訂，您可以加快 TLS 握手。 在線證書狀態協議 (OCSP) 是作為證書撤銷列表 (CRL) 協議的替代方案而創建的。 這兩種協議都用於檢查 SSL 證書是否已被吊銷。

    但是，OCSP 協議不需要瀏覽器花時間下載然後搜索證書信息列表，因此減少了握手所需的時間。

  2. 您是否減少了 SSL 證書吊銷的影響？
    在他關於“EV 證書的性能成本”的文章中，Simon Hearne 對常見證書進行了很好的概述，以及證書的選擇可能對整體性能產生的影響。

    正如 Simon 所寫，在 HTTPS 的世界中，有幾種類型的證書驗證級別用於保護流量：

    • 域驗證(DV) 驗證證書請求者是否擁有該域，
    • 組織驗證(OV) 驗證組織是否擁有該域，
    • 擴展驗證(EV) 通過嚴格的驗證來驗證組織是否擁有該域。

    需要注意的是，所有這些證書在技術方面都是相同的。 它們僅在這些證書中提供的信息和屬性上有所不同。

    EV 證書既昂貴又耗時，因為它們需要人工審核證書並確保其有效性。 另一方面，DV 證書通常是免費提供的——例如由 Let's Encrypt——一個開放的、自動化的證書頒發機構，它很好地集成到許多託管服務提供商和 CDN 中。 事實上，在撰寫本文時，它為超過 2.25 億個網站 (PDF) 提供支持，儘管它僅佔頁面的 2.69%（在 Firefox 中打開）。

    那麼有什麼問題呢？ 問題是EV 證書不完全支持上面提到的 OCSP 裝訂。 雖然裝訂允許服務器與證書頒發機構檢查證書是否已被吊銷，然後將此信息添加（“裝訂”）到證書中，而無需裝訂客戶端必須完成所有工作，從而導致在 TLS 協商期間產生不必要的請求. 在連接不佳的情況下，這可能會導致顯著的性能成本（1000 毫秒以上）。

    EV 證書對於 Web 性能來說並不是一個很好的選擇，而且它們對性能的影響要比 DV 證書大得多。 為獲得最佳 Web 性能，請始終提供 OCSP 裝訂的 DV 證書。 它們也比 EV 證書便宜得多，而且獲得的麻煩更少。 好吧，至少在 CRLite 可用之前。

    顯示在普通、壓縮或兩者的情況下沿站點 UDP 數據報的握手次數的圖表
    壓縮很重要：40-43% 的未壓縮證書鏈太大而無法容納 3 個 UDP 數據報的單個 QUIC 飛行。 （圖片來源：）快速）（大預覽）

    注意：使用 QUIC/HTTP/3，值得注意的是 TLS 證書鍊是一個可變大小的內容，它在 QUIC 握手中支配字節數。 大小在幾百字節和超過 10 KB 之間變化。

    因此，在 QUIC/HTTP/3 上保持 TLS 證書很小很重要，因為大型證書會導致多次握手。 此外，我們需要確保證書被壓縮，否則證書鏈將太大而無法容納在單個 QUIC 飛行中。

    您可以在以下位置找到更多詳細信息和指向問題和解決方案的方法：

    • EV 證書使 Web 變得緩慢且不可靠 作者 Aaron Peters，
    • SSL 證書吊銷對 Web 性能的影響 by Matt Hobbs，
    • Simon Hearne 的 EV 證書的性能成本，
    • QUIC 握手是否需要快速壓縮？ 通過帕特里克麥克馬納斯。
  3. 您採用 IPv6 了嗎？
    因為我們的 IPv4 空間已經用完，而且主要移動網絡正在迅速採用 IPv6（美國幾乎達到了 50% 的 IPv6 採用閾值），所以最好將您的 DNS 更新為 IPv6，以防萬一。 只需確保跨網絡提供雙棧支持——它允許 IPv6 和 IPv4 同時運行。 畢竟，IPv6 不是向後兼容的。 此外，研究表明，由於鄰居發現 (NDP) 和路由優化，IPv6 使這些網站的速度提高了 10% 到 15%。
  4. 確保所有資產都通過 HTTP/2（或 HTTP/3）運行。
    隨著谷歌在過去幾年中推動更安全的 HTTPS 網絡，切換到 HTTP/2 環境絕對是一項不錯的投資。 事實上，根據 Web Almanac，64% 的請求已經在 HTTP/2 上運行。

    重要的是要了解 HTTP/2 並不完美並且存在優先級問題，但它得到了很好的支持； 而且，在大多數情況下，你會更好。

    提醒一句：HTTP/2 Server Push 正在從 Chrome 中刪除，因此如果您的實現依賴於 Server Push，您可能需要重新訪問它。 相反，我們可能正在研究 Early Hints，它已經作為實驗集成在 Fastly 中。

    如果您仍然在 HTTP 上運行，最耗時的任務將是首先遷移到 HTTPS，然後調整您的構建過程以適應 HTTP/2 多路復用和並行化。 將 HTTP/2 引入 Gov.uk 是一個非常棒的案例研究，可以在此過程中通過 CORS、SRI 和 WPT 找到方法。 對於本文的其餘部分，我們假設您正在切換到或已經切換到 HTTP/2。

圖表顯示了從 2016 年 1 月 2 日到 2020 年 10 月 1 日桌面和移動設備中 HTTP/2 請求的時間序列
根據 Web Almanac 的數據，到 2020 年底，64% 的請求都通過 HTTP/2 提供服務——距離其正式標準化僅 4 年。 （圖片來源：Web Almanac）（大預覽）
  1. 正確部署 HTTP/2。
    同樣，通過 HTTP/2 提供資產可以受益於對迄今為止提供資產的方式進行部分改革。 您需要在打包模塊和並行加載許多小模塊之間找到一個很好的平衡點。 歸根結底，最好的請求仍然是沒有請求，但是，目標是在快速首次交付資產和緩存之間找到一個很好的平衡點。

    一方面，您可能希望避免完全連接資產，而不是將整個界面分解為許多小模塊，將它們作為構建過程的一部分進行壓縮並並行加載。 一個文件的更改不需要重新下載整個樣式表或 JavaScript。 它還最大限度地減少了解析時間，並使各個頁面的有效負載保持在較低水平。

    另一方面，包裝仍然很重要。 通過使用許多小腳本，整體壓縮會受到影響，並且從緩存中檢索對象的成本會增加。 大包的壓縮將受益於字典重用，而單獨的小包則不會。 有標準的工作來解決這個問題，但現在還很遙遠。 其次，瀏覽器尚未針對此類工作流程進行優化。 例如，Chrome 會觸發與資源數量成線性關係的進程間通信 (IPC)，因此包含數百個資源將產生瀏覽器運行時成本。

    使用漸進式 CSS 加載的 HTML 代碼
    要使用 HTTP/2 獲得最佳結果，請考慮逐步加載 CSS，正如 Chrome 的 Jake Archibald 所建議的那樣。

    不過，您可以嘗試逐步加載 CSS。 事實上，in-body CSS 不再阻礙 Chrome 的渲染。 但是有一些優先級問題，所以它不是那麼簡單，但值得嘗試。

    您可以使用 HTTP/2 連接合併，它允許您在受益於 HTTP/2 的同時使用域分片，但在實踐中實現這一點很困難，而且通常不被認為是好的做法。 此外，HTTP/2 和子資源完整性並不總是有效。

    該怎麼辦？ 好吧，如果你在 HTTP/2 上運行，發送大約6-10 個包似乎是一個不錯的折衷方案（對於舊版瀏覽器來說還不錯）。 試驗和測量以找到適合您網站的平衡點。

  2. 我們是否通過單個 HTTP/2 連接發送所有資產？
    HTTP/2 的主要優點之一是它允許我們通過單個連接將資產發送到線路上。 然而，有時我們可能做錯了什麼——例如有一個 CORS 問題，或者錯誤配置了crossorigin屬性，所以瀏覽器將被迫打開一個新連接。

    要檢查所有請求是否使用單個 HTTP/2 連接，或者是否配置錯誤，請啟用 DevTools → Network 中的“Connection ID”列。 例如，在這裡，所有請求共享相同的連接 (286) — 除了 manifest.json，它打開一個單獨的連接 (451)。

在 Chrome 瀏覽器中打開的 DevTools 的屏幕截圖
所有請求共享相同的 HTTP/2 連接 (286) — 除了 manifest.json，它打開一個單獨的 (451)。 通過iamakulov。 （大預覽）
  1. 您的服務器和 CDN 是否支持 HTTP/2？
    不同的服務器和 CDN（仍然）以不同的方式支持 HTTP/2。 使用 CDN 比較來檢查您的選項，或快速查看您的服務器的性能以及您期望支持的功能。

    請參閱 Pat Meenan 關於 HTTP/2 優先級（視頻）的令人難以置信的研究，並測試服務器對 HTTP/2 優先級的支持。 根據 Pat 的說法，建議啟用 BBR 擁塞控制並將tcp_notsent_lowat設置為 16KB，以便 HTTP/2 優先級在 Linux 4.9 內核及更高版本上可靠地工作（感謝 Yoav！ ）。 Andy Davies 對跨瀏覽器、CDN 和雲託管服務的 HTTP/2 優先級進行了類似的研究。

    使用它時，請仔細檢查您的內核是否支持 TCP BBR，並在可能的情況下啟用它。 它目前用於 Google Cloud Platform、Amazon Cloudfront、Linux（例如 Ubuntu）。

  2. 是否正在使用 HPACK 壓縮？
    如果您使用的是 HTTP/2，請仔細檢查您的服務器是否為 HTTP 響應標頭實施 HPACK 壓縮，以減少不必要的開銷。 一些 HTTP/2 服務器可能不完全支持該規範，HPACK 就是一個例子。 H2spec 是一個很棒的（如果技術上非常詳細）工具來檢查它。 HPACK 的壓縮算法令人印象深刻，而且它確實有效。
  3. 確保服務器上的安全性是防彈的。
    HTTP/2 的所有瀏覽器實現都通過 TLS 運行，因此您可能希望避免出現安全警告或頁面上的某些元素不起作用。 仔細檢查您的安全標頭是否設置正確，消除已知漏洞，並檢查您的 HTTPS 設置。

    此外，確保所有外部插件和跟踪腳本都是通過 HTTPS 加載的，跨站點腳本是不可能的，並且 HTTP 嚴格傳輸安全標頭和內容安全策略標頭都已正確設置。

  4. 您的服務器和 CDN 是否支持 HTTP/3？
    雖然 HTTP/2 為 Web 帶來了許多顯著的性能改進，但它也留下了相當多的改進空間——尤其是 TCP 中的線頭阻塞，這在具有嚴重數據包丟失的慢速網絡上很明顯。 HTTP/3 正在徹底解決這些問題（文章）。

    為了解決 HTTP/2 問題，IETF 與 Google、Akamai 和其他公司一起，一直在研究一種新協議，該協議最近被標準化為 HTTP/3。

    Robin Marx 已經很好地解釋了 HTTP/3，下面的解釋是基於他的解釋。 就其核心而言，HTTP/3 在功能方面與 HTTP/2 非常相似，但在底層它的工作方式卻大不相同。 HTTP/3 提供了許多改進：更快的握手、更好的加密、更可靠的獨立流、更好的加密和流控制。 一個顯著的區別是 HTTP/3 使用 QUIC 作為傳輸層，QUIC 數據包封裝在 UDP 圖而不是 TCP 之上。

    QUIC 將 TLS 1.3 完全集成到協議中，而在 TCP 中它是分層的。 在典型的 TCP 堆棧中，我們有一些往返時間的開銷，因為 TCP 和 TLS 需要自己進行單獨的握手，但是使用 QUIC 可以將它們組合在一起並在一次往返中完成。 由於 TLS 1.3 允許我們為後續連接設置加密密鑰，從第二個連接開始，我們已經可以在第一次往返中發送和接收應用層數據，稱為“0-RTT”。

    此外，HTTP/2 的標頭壓縮算法及其優先級系統也被完全重寫。 此外，QUIC 通過每個 QUIC 數據包標頭中的連接 ID 支持從 Wi-Fi 到蜂窩網絡的連接遷移。 大多數實現都是在用戶空間完成的，而不是內核空間（就像 TCP 一樣），所以我們應該期待協議在未來不斷發展。

    這一切都會有很大的不同嗎？ 可能是的，尤其是對移動設備的加載時間有影響，而且對我們如何向最終用戶提供資產也有影響。 在 HTTP/2 中，多個請求共享一個連接，而在 HTTP/3 中，請求也共享一個連接但獨立流式傳輸，因此丟棄的數據包不再影響所有請求，只會影響一個流。

    這意味著，雖然使用一個大型 JavaScript 包，當一個流暫停時資產的處理速度會減慢，但當多個文件並行流 (HTTP/3) 時，影響將不那麼顯著。 所以包裝仍然很重要。

    HTTP/3 仍在進行中。 Chrome、Firefox 和 Safari 已經有了實現。 一些 CDN 已經支持 QUIC 和 HTTP/3。 2020 年底，Chrome 開始部署 HTTP/3 和 IETF QUIC，實際上所有 Google 服務（Google Analytics、YouTube 等）都已經在 HTTP/3 上運行。 LiteSpeed Web Server 支持 HTTP/3，但 Apache、nginx 或 IIS 都不支持它，但它很可能在 2021 年迅速改變。

    底線：如果您可以選擇在服務器和 CDN 上使用 HTTP/3，那麼這樣做可能是一個非常好的主意。 主要好處將來自同時獲取多個對象，尤其是在高延遲連接上。 我們還不確定，因為在該領域沒有太多研究，但初步結果非常有希望。

    如果您想更深入地了解協議的細節和優勢，這裡有一些很好的起點來檢查：

    • HTTP/3 Explained，一個記錄 HTTP/3 和 QUIC 協議的協作努力。 有多種語言版本，也有 PDF 格式。
    • Daniel Stenberg 使用 HTTP/3 提升 Web 性能。
    • 與 Robin Marx 合作的 QUIC 學術指南介紹了 QUIC 和 HTTP/3 協議的基本概念，解釋了 HTTP/3 如何處理線頭阻塞和連接遷移，以及 HTTP/3 如何被設計為常青樹（感謝Simon ！）。
    • 您可以在 HTTP3Check.net 上檢查您的服務器是否在 HTTP/3 上運行。

目錄

  1. 準備：計劃和指標
  2. 設定切合實際的目標
  3. 定義環境
  4. 資產優化
  5. 構建優化
  6. 交付優化
  7. 網絡、HTTP/2、HTTP/3
  8. 測試和監控
  9. 快速獲勝
  10. 一切都在一頁上
  11. 下載清單（PDF、Apple Pages、MS Word）
  12. 訂閱我們的電子郵件通訊不要錯過下一個指南。