• 原文地址：Front-End Performance Checklist 2019 — 6
  • 原文作者：Vitaly Friedman
  • 譯文出自：掘金翻譯計劃
  • 本文永久鏈接：github.com/xitu/gold-mi
  • 譯者：子非
  • 校對者：Ivocin，weibinzhu

2019 前端性能優化年度總結 — 第六部分

讓 2019 來得更迅速吧~ 你正在閱讀的是 2019 年前端性能優化年度總結，始於 2016。

內容目錄

  • HTTP/2
    • 52. 遷移到 HTTPS，然後啟用 HTTP/2
    • 53. 合適地部署 HTTP/2
    • 54. 你的伺服器和 CDN 支持 HTTP/2 嗎？
    • 55. OCSP Stapling 是否啟用？
    • 56. 你採用 IPv6 了嗎？
    • 57. 是否使用 HPACK 壓縮？
    • 58. 確保你的伺服器安全穩固
  • 測試和監控
    • 59. 你優化過你的審計流程嗎？
    • 60. 你測試過代理和過時的瀏覽器嗎？
    • 61. 你測試過輔助工具的性能嗎？
    • 62. 是否設置了持續監控？
  • 速效方案
  • 下載清單（PDF，Apple Pages）
  • 出發！

HTTP/2

52. 遷移到 HTTPS，然後啟用 HTTP/2

隨著 Google 推進更安全的 web 並最終所有的 HTTP 頁面都被 Chrome 視為「不安全」，向 HTTP/2 環境轉變已經不可避免。HTTP/2 現在已經得到了很好的支持；它沒有任何大的改變；並且在大多數情況下，使用它會讓你得到出色的性能表現。一旦在已經 HTTPS 運行了，你可以使用 service workes 和 server push 得到巨大的性能提升（至少長期來看）。

最終 Google 打算標記所有 HTTP 頁面為非安全，並把 Chrome 標記失效 HTTPS 用的紅色三角形作為 HTTP 的安全性指示器。（圖像來源）

最耗時的工作將會是遷移至 HTTPS，並且根據你的 HTTP/1.1 用戶（使用過時操作系統和瀏覽器的用戶）數量你不得不要考慮過時瀏覽器的性能優化而發送不同構建的版本，這需要你採納不同的構建進程。注意：配置遷移和新的構建進程會很麻煩且耗時。在本文的餘下內容中，我會假設你正在或已經遷移 HTTP/2。

53. 合適地部署 HTTP/2

為讓資源通過 HTTP/2 傳遞需要對現在提供資源的方式進行部分修改。你需要在打包成一個大模塊和並行載入許多小模塊之間找到合適的平衡。最好的請求就是沒有請求，然而目標是在首次快速分發資源和緩存之間找到一個好的平衡。

一方面，你可能想避免資源全都合併在一起，而是把全部的介面分割成許多小的模塊，把它們壓縮為構建進程的一部分，通過 「偵查」途徑引用並並行載入它們。一個文件的改變不需要重新載入全部樣式或 JavaScript 。它還壓縮解析時間並使每個頁面保持少量的資源負載。

另一方面，打包仍然是個問題。首先，壓縮會受到影響。大模塊壓縮會受益於字典復用，而小的獨立模塊不會。是有一些標準來解決這個問題，但是目前還差得很遠。第二，瀏覽器針對這種流程還沒有做優化。例如，Chrome 會觸發數量和資源數線性相關的進程間通訊（IPC），這樣大量的資源會消耗瀏覽器運行時。

為了獲得使用 HTTP/2 的最佳效果，請考慮漸進式載入 CSS，這是來自 Chrome 成員 Jake Archibald 的建議。

你可以嘗試漸進載入式 CSS。實際上，自從 Chrome 69 開始，body 內的 CSS 已經不再阻塞 Chrome 的渲染。顯然，這樣做不利於使用 HTTP/1.1 的用戶，所以你可能需要為不同的瀏覽器生成並提供不同的構建，來作為你的調度進程一部分，事情會稍微更複雜一些。你可能會使用 HTTP/2 連接聚合來避免，它允許你利用 HTTP/2 使用域切分，但實際上並不容易做到，總之，它被不認為是最佳實踐。

該怎麼做呢？如果你正在運行 HTTP/2，那麼發送大約 6-10 個包 會是一個不錯的折中方案（並且對於老舊瀏覽器也不會太糟糕）。需要試驗和測試來為你的網站找到最佳的平衡。

54. 你的伺服器和 CDN 支持 HTTP/2 嗎？

不同的伺服器和 CDN 可能可能對 HTTP/2 的支持不一樣。使用 TLS 速度快嗎？來檢查你的配置，或快速查找伺服器的運行情況以及可以支持的功能。

我參考了 Pat Meenan 非常棒的 HTTP/2 優先順序的研究和測試伺服器的支持程度以確定 HTTP/2 優先順序。依據 Pat 的研究，為了讓 HTTP/2 優先順序能可靠地工作在 Linux 4.9 以及更新的內核上，推薦開啟 BBR 堵塞控制和設置 tcp_notsent_lowat 為 16 KB（感謝 Yoav！）。Andy Davies 在多個瀏覽器上做了類似的 HTTP/2 優先順序研究，CDN 和雲託管服務。

TLS 速度快嗎？允許你在切換到 HTTP/2 時檢查你的伺服器和 CDN 的配置 (大預覽圖)

55. OCSP Stapling 是否啟用？

通過在你的伺服器上啟用 OCSP Stapling，可以加速 TLS 握手。創建在線證書狀態協議（Online Certificate Status Protocol）（OCSP）是作為證書撤銷列表（Certificate Revocation List）（CRL）協議的代替。兩種協議都是用來檢查 SSL 證書是否被撤銷。然而，OCSP 協議不需要瀏覽器花費時間下載然後在列表中搜尋證書信息，因此能減少握手需要的時間。

56. 你採用 IPv6 了嗎？

因為 IPv4 地址正在消耗殆盡並且主要的手機網路正在迅速接受 IPv6（美國已經達到 50% IPv6 採納率），更新你的 DNS 為 IPv6 是一個不錯的想法，這樣在將來可以保持伺服器安全穩固。只需要確認網路是否支持雙棧 —— 它允許 IPv6 和 IPv4 同時工作。別忘了，IPv6 並不向後兼容。並且，研究表明 得益於鄰居發現（NDP）和路由優化， IPv6 使這些網站提速了 10 到 15%。

57. 是否使用 HPACK 壓縮？

如果你在使用 HTTP/2，請確保檢查你的伺服器為 HTTP 響應頭實現了 HPACK 壓縮來減少不必要的載荷。因為 HTTP/2 伺服器都比較新，它們也許沒有完全支持設計規範，HPACK 就是一個例子，H2spec 是一個出色的（從技術上講很詳盡）檢查工具。HPACK 的壓縮演算法確實令人印象深刻，並且運行效果不錯。

58. 確保你的伺服器安全穩固

所有瀏覽器的 HTTP/2 實現都是運行在 TLS 之上，所以你可能想避免安全性警告或頁面中的某些元素出錯。請確保 HTTP 頭在安全方面得到合適配置，消除已知的風險，並且檢查你的證書。還有確保通過 HTTPS 載入所有的外部插件和跟蹤腳本，沒有跨站腳本並且已經合適地配置了 HTTP 嚴格傳輸安全頭和內容安全策略頭。

測試和監控

59. 你優化過你的審計流程嗎？

可能聽起來沒什麼大不了的，但是如果設置合適可能會減少你很多測試上的時間。請考慮使用 Tim Kadlec 的針對 WebPageTest 的 Alfred 工作流向 WebPageTest 公共實例來提交測試用例。

你也可以用 Google Spreadsheet 來驅動 WebPageTest 並且 Travis 使用 Lighthouse CI 安裝了包含輔助工具，性能和 SEO 評分的測試或直接打包進 Webpack。

並且如果你需要快速調試東西但你的構建進程似乎奇慢，記住「對於大部分 JavaScript 來說移除空白符和 symbol mangling 可以使被壓縮代碼大小減少 95% —— 並不是精巧的代碼轉換。你可以簡單的通過壓縮使 Uglify 構建速度快 3 到 4 倍。」

通過使用 Lighthouse CI 在 Travis 中集成輔助性工具，性能和 SEO 評分測試對所有的合作開發者來說都能顯著提升開發新功能的效率。（圖像來源）（大預覽圖）

60. 你測試過代理和過時的瀏覽器嗎？

光測試 Chrome 和 Firefox 還不夠。看看你的網站在代理瀏覽器和過時瀏覽器中的表現。例如在亞洲有著巨大的市場佔有率（在亞洲多達 35%）的 UC 瀏覽器和 Opera Mini。評估平均網路速度以避免在你的國家出現載入非常慢的情況。使用網路節流和模擬高解析度設備測試。BrowserStack 非常不錯，不過還是要在真機上測試。

k6 允許你寫類似單元測試的性能測試用例。

61. 你測試過輔助工具的性能嗎？

當瀏覽器開始載入頁面，它創建 DOM，如果此時有例如屏幕閱讀器的輔助技術在運行，它也會創建輔助樹。屏幕閱讀器必須查詢輔助樹來獲取信息並讓讀者可用 —— 有時默認直接查詢，有時是按需，並且它可能會消耗一些時間。

當討論到快速到達可交互狀態，通常我們指用戶能儘快通過點擊鏈接或按鈕來與頁面交互的指標。這個概念與屏幕閱讀器的有細微不同。對於屏幕閱讀器來說，最快可交互時間是指當屏幕閱讀器可以讀出給定頁面的導航並且使用者可以實際敲擊鍵盤來交互時的時間過去了多少。

Léonie Watson 有一個在輔助性工具的性能方面令人眼界大開的討論並且特別指出載入慢會導致屏幕閱讀器閱讀延遲。屏幕閱讀器本是用來快速閱讀並導航的，因此可能那些視力不好的用戶會比視力好的用戶缺少耐心。

載入大頁面和使用 JavaScript 操作 DOM 會導致屏幕閱讀器語音延遲。請關注這些以前沒注意到的地方，並測試所有可用的平台（Jaws，NVDA，Voiceover，Narrator，Orca）。

62. 是否建立持續監控？

對於快速無限制測試來說持有一個 WebPagetest 實例總是非常受益的。一個類似 Sitespeed，Calibre 和 SpeedCurve 的可持續監控工具能自動報警，給你更詳盡的性能畫像。設置你自己的用戶時間記錄來測試和監控特殊業務指標。並請考慮加入自動性能回歸警報來監控變化。

了解使用 RUM-solutions 來監控性能隨時間的變化。對於像載入測試工具的自動化測試，你可以使用 k6 和它的腳本 API。並了解 SpeedTracker，Lighthouse 和 Calibre。

速效方案

本文的清單相當全面，並且完成所有的優化需要相當一段時間。所以，如果你只有一小時但想獲得巨大性能提升，你要怎麼做？讓我們總結為 12 條易於實現的目標。顯然，在你開始之前和完成之後，評估結果，包括在 3G 和有線網路連接下的渲染時間和 Speed Index。

  1. 評估實際經驗和設置合適的目標。一個很好的目標是追求首次有意義的渲染時間 < 1 秒，同時 Speed Index < 1250 秒，慢速 3G 網路下首次可交互時間 < 5秒，TTI < 2 秒。針對渲染時間和首次可交互時間做優化。
  2. 為你的主要模板準備關鍵 CSS，並在放在頁面的 head 標籤內（預算應小於 14 KB）。對於 CSS/JS，使它們小於關鍵文件大小最大預算 gzipped 壓縮後為 170 KB（未壓縮為 0.7 MB）。
  3. 儘可能地讓更多的腳本分割，優化，defer 載入或者懶載入，檢查輕量級的可選包並限制第三方包的大小。
  4. 使用 <script type="module"> 來讓代碼只對舊瀏覽器工作。
  5. 試著整個 CSS 規則並測試 in-body CSS。
  6. 使用更快的 dns-lookup，preconnect，prefetch 和 preload 來添加資源提示來加速分發。
  7. 給網路字體分組並非同步載入，在 CSS 中利用 font-display 來加速首次渲染。
  8. 優化圖片，並考慮為重要的頁面（例如首頁）使用 WebP。
  9. 檢查 HTTP 頭設置的緩存並確保已經被合適地設置。
  10. 在伺服器上啟用 Brotli 和 Zopfli 壓縮。（如果不能，別忘了啟用 Gzip 壓縮。）
  11. 如果 HTTP/2 可用，啟用 HPACK 壓縮並開始監控 mixed-content 警告。開啟 OSCP 壓縮。
  12. 在 service worker 中緩存字體，樣式，JavaScript 和圖片等資源文件。

下載清單 （PDF，Apple Pages）

記住這條清單，你應該就能應對各種前端性能方面的項目。請自由下載可列印版的 PDF 清單，同時為了供您按需定製清單還準備了可編輯的 Apple Pages 文檔。

  • 下載 PDF 版清單 (PDF，166 KB)
  • 下載 Apple Pages 版清單 (.pages，275 KB)
  • 下載 MS Word 版清單 (.docx，151 KB)

如果你需要更多選擇，你也可以查看 Dan Rublic 總結的前端清單，Jon Yablonski 總結的設計者的 Web 性能清單 和 FrontendChecklist。

出發！

一些優化可能超出你的工作或計劃，或者對於你要處理的老舊代碼可能造出更多麻煩。這都不是問題！請把這個清單作為一個（希望夠全面）大綱，創建適合你的專屬的問題清單。不過重中之重的是優化前測試和權衡你的項目來定位問題。希望大家在 2019 年都能得到不錯的優化成績！

非常感謝 Guy Podjarny，Yoav Weiss，Addy Osmani，Artem Denysov，Denys Mishunov，Ilya Pukhalski，Jeremy Wagner，Colin Bendell，Mark Zeman，Patrick Meenan，Leonardo Losoviz，Andy Davies，Rachel Andrew，Anselm Hannemann，Patrick Hamann，Andy Davies，Tim Kadlec，Rey Bango，Matthias Ott，Peter Bowyer，Phil Walton，Mariana Peralta，Philipp Tellis，Ryan Townsend，Ingrid Bergman，Mohamed Hussain S. H.，Jacob Gro?，Tim Swalling，Bob Visser，Kev Adamson，Adir Amsalem，Aleksey Kulikov 和 Rodney Rehm 對這篇文章的審閱，同時也感謝我們無與倫比的社區，大家會分享從工作學到的，對每個人都有用的優化技術和課程。你們真的是太棒了！

  • [譯] 2019 前端性能優化年度總結 — 第一部分
  • [譯] 2019 前端性能優化年度總結 — 第二部分
  • [譯] 2019 前端性能優化年度總結 — 第三部分
  • [譯] 2019 前端性能優化年度總結 — 第四部分
  • [譯] 2019 前端性能優化年度總結 — 第五部分
  • [譯] 2019 前端性能優化年度總結 — 第六部分

如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久鏈接 即為本文在 GitHub 上的 MarkDown 鏈接。

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。

推薦閱讀：

相关文章