[譯] 2019 前端效能優化年度總結 — 第六部分

子非發表於2019-02-11

原文地址：Front-End Performance Checklist 2019 — 6

原文作者：Vitaly Friedman

譯文出自：掘金翻譯計劃

本文永久連結：github.com/xitu/gold-m…

譯者：子非

校對者：Ivocin，weibinzhu

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

[譯] 2019 前端效能優化年度總結 — 第一部分

[譯] 2019 前端效能優化年度總結 — 第二部分

[譯] 2019 前端效能優化年度總結 — 第三部分

[譯] 2019 前端效能優化年度總結 — 第四部分

[譯] 2019 前端效能優化年度總結 — 第五部分

[譯] 2019 前端效能優化年度總結 — 第六部分

內容目錄

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 秒，同時 Speed Index < 1250 秒，慢速 3G 網路下首次可互動時間 < 5秒，TTI < 2 秒。針對渲染時間和首次可互動時間做優化。
為你的主要模板準備關鍵 CSS，並在放在頁面的 head 標籤內（預算應小於 14 KB）。對於 CSS/JS，使它們小於關鍵檔案大小最大預算 gzipped 壓縮後為 170 KB（未壓縮為 0.7 MB）。
儘可能地讓更多的指令碼分割，優化，defer 載入或者懶載入，檢查輕量級的可選包並限制第三方包的大小。
使用 <script type="module"> 來讓程式碼只對舊瀏覽器工作。
試著整個 CSS 規則並測試 in-body CSS。
使用更快的 dns-lookup，preconnect，prefetch 和 preload 來新增資源提示來加速分發。
給網路字型分組並非同步載入，在 CSS 中利用 font-display 來加速首次渲染。
優化圖片，並考慮為重要的頁面（例如首頁）使用 WebP。
檢查 HTTP 頭設定的快取並確保已經被合適地設定。
在伺服器上啟用 Brotli 和 Zopfli 壓縮。（如果不能，別忘了啟用 Gzip 壓縮。）
如果 HTTP/2 可用，啟用 HPACK 壓縮並開始監控 mixed-content 警告。開啟 OSCP 壓縮。
在 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 對這篇文章的審閱，同時也感謝我們無與倫比的社群，大家會分享從工作學到的，對每個人都有用的優化技術和課程。你們真的是太棒了！