（譯）2019年前端效能優化清單 — 下篇
隨著 Google 向更安全的網路發展 ，並最終將 Chrome 中的所有 HTTP 網頁認定為 不安全 的大環境下，遷移到HTTP / 2環境 是不可避免的。 HTTP / 2 從目前來看得到很好的支援 ， 而且，在大多數場景下，使用 HTTP/2 會讓你大力出奇。一旦在 HTTPS 上執行，您可以在 service workers 和 server push 方面得到顯著的效能提升。
最終，谷歌計劃將所有 HTTP 頁面標記為不安全的，並將有問題的 HTTPS 的 HTTP 安全指示器更改為紅色三角形。
最耗時的任務是遷移到 HTTPS，不過這取決於你的 HTTP/1.1 使用者量有多大（即使用舊版作業系統或瀏覽器的使用者），你將不得不為舊版的瀏覽器效能優化傳送不同的構建版本，這需要你採用不同的構建流程。注意：開始遷移和新的構建過程可能會很棘手，而且耗費時間。接下來所講的內容，都是針對之前切過 HTTP/2 環境或者現在正準備切 HTTP/2 環境（的讀者）來展開的。
53. 正確部署HTTP / 2
再次強調一下，需要對現階段正如何提供在你開始使用 HTTP/2 請求資源之前，需要搞清楚你以前是如何請求資源的。另外需要你在載入大模組以及並行載入小模組之間找到一個平衡點。最終，仍然是 最好的請求就是沒有請求 ，然而我們的目標是在快速傳輸資源和快取之間找到一個好的平衡點。。
一方面，你可能想要避免合併所有資源，而是把整個介面分解成許多小模組，然後在構建過程中壓縮這些小模組，最後通過 scount approach 的方法 引用和並行載入這些小模組。這樣的話，一個檔案的更改就不需要重新下載整個樣式表或 JavaScript。這樣還可以最小化解析時間，並將單個頁面的負荷保持在較低的水平。
另一方面，打包仍然很重要。首先， 壓縮將讓你受益 。在壓縮大檔案的過程中，藉助目錄重用的特點，達到優化效能的目的，而小的單獨的檔案則不會。有標準的工作來解決這個問題，但現在還遠遠不夠。其次，瀏覽器還 沒有為這種工作流優化 。例如，Chrome 將觸發程序間通訊（IPCs），與資源的數量成線性關係，因此頁面中如果包含數以百計的資源將會造成瀏覽器效能損失。
, Chrome 的 Jake Archibald 建議我們這樣做。
你可以嘗試漸進載入 CSS。事實上，由於 Chrome 69 版本，內部 CSS不再阻止 Chrome 渲染。顯然，這種做法不利於 HTTP / 1.1 使用者，所以你可能需要針對不同的瀏覽器建立併發送該瀏覽器支援的 HTTP 協議報頭，這還只是部署過程中稍微複雜的地方。不過你可以使用 HTTP/2 的 connection coalescing ，他可以讓你在 HTTP/2 環境使用域名共享來避免這個問題，但是這個做法在實際的實踐當中會比較困難。
那要怎麼做呢？如果你執行在 HTTP/2 之上，傳送 6-10 個包是個最理想的折中點（對傳統瀏覽器也適用）。對於你自己的網站，你可以通過實驗和測量來找到最佳的平衡點。
54. 您的伺服器和 CDN 是否支援 HTTP / 2
不同的伺服器和 CDN 可能會以不同的方式支援 HTTP / 2。快速使用TLS 檢查您的選項，或快速查詢伺服器的效能，或者您希望看到可以支援的特性。
參考 Pat Meenan 對HTTP / 2優先順序 和 測試伺服器支援HTTP / 2優先順序 的的研究。根據 Pat 的說法，建議啟用 BBR 擁塞控制並將其設定 tcp_notsent_lowat 為 16KB 以進行 HTTP / 2 優先順序排序，以便在 Linux 4.9 核心及更高版本上可靠地執行（感謝Yoav！）。Andy Davies對跨瀏覽器， CDN和雲託管服務的 HTTP / 2優先順序 進行了類似的研究。
?允許您在切換到HTTP/2時檢查伺服器和CDNs選項。
55. 是否啟用了 OCSP stapling
通過 在您的伺服器上啟用 OCSP stapling ，可以加快 TLS 握手速度。線上證書狀態協議（OCSP）作為證書撤銷列表（CRL）協議的替代方案。兩種協議都用於檢查 SSL 證書是否已被撤銷。但是，OCSP 協議不要求瀏覽器花時間下載然後在列表中搜索證書資訊，因此減少握手所需要的時間。
56. 是否採用 IPv6
由於我們的IPv4空間不足，而主要行動網路正在迅速採用 IPv6（美國已經達到了 50％ 的 IPv6 採用率閾值），因此最好將DNS更新為IPv6 以保證未來的防範。只需確保通過網路提供雙棧支援 - 它允許 IPv6 和 IPv4 同時並行執行。畢竟，IPv6 不是向後相容的。此外，有研究表明，正是因為 IPv6 自帶 NDP 以及路由優化，所以才能夠讓網站的載入速度提升 10% 到 15%。
57. 是否正在使用 HPACK 壓縮
如果您使用的是 HTTP / 2，請仔細檢查您的伺服器是否為 HTTP 響應標頭實施HPACK壓縮，以減少不必要的開銷。由於 HTTP / 2 伺服器相對較新，它們可能不完全支援規範，就比如 HPACK。 H2spec 是一個用來檢查的很好的工具，他壓縮演算法 非常有效。
58. 確保伺服器上的安全性是防攻擊的
HTTP / 2 的所有瀏覽器實現都通過 TLS 執行，因此您可能希望頁面避免出現安全警告或者是頁面上的某些互動無法正常實現。這時候您需要仔細檢查您的安全標頭是否設定正確以及 證書 ，來消除已知漏洞 。另外，請確保通過HTTPS載入所有外部外掛和跟蹤指令碼，無法進行跨站點指令碼編寫，並且網站已經正確設定了HTTP嚴格傳輸安全標頭 和內容安全策略標頭。
測試和監測
59. 您是否優化了審計和除錯工作流程
從字面上來看這可能不是什麼影響效能的大問題，但在觸手可及的地方設定合適的設定可能會為給您節省大量的測試時間。可以考慮使用 Tim Kadlec 的 WebPageTest 中的 Alfred Workflow 將測試提交給 WebPageTest 的公共例項。您還可以從 Google電子表格中驅動WebPageTest ，並將可訪問性，效能和 SEO 分數納入您使用 Lighthouse CI 的 Travis 設定或直接使用Webpack。
整合到 Travis 設定中，可以突出顯示新功能對所有貢獻開發人員的效能影響。
60. 您是否在代理瀏覽器和傳統瀏覽器中測試過
僅僅在 Chrome 和 Firefox 瀏覽器進行測試是不夠的。我們還需要了解網站在代理瀏覽器和舊版瀏覽器中的工作方式。例如，UC 瀏覽器 和 Opera Mini ，這些瀏覽器 在亞洲佔有很大的市場份額 （ 高達35％ ）。測量您感興趣的國家/地區的平均網際網路速度，以避免出現重大意外情況。測試網路節流，並模擬一個高 DPI 裝置。BrowserStack 很不錯，但也要在實際裝置上測試。
允許您編寫單元測試 - 類似的效能測試。
61. 您是否測試了輔助功能
當瀏覽器開始載入頁面時，它構建一個DOM，如果有像螢幕閱讀器這樣的輔助技術在執行，它還會建立一個可訪問性樹。然後螢幕閱讀器會通過查詢可訪問性樹來檢索資訊並使其對使用者可用 —— 這有時是預設的，有時是按需的。
我們所說的快速互動時間，通常指的是使用者通過點選連結和按鈕與頁面互動的速度。當螢幕閱讀器的上下文略有不同的時候，快速互動時間意味著螢幕閱讀器可以在頁面顯示導航，到螢幕閱讀器上的使用者可以用鍵盤與頁面進行互動所需的時間。
萊內·沃森（LéonieWatson） 在易訪問性效能方面 做了一次大開眼界的演講，特別是慢載入對螢幕閱讀器釋出延遲的影響。螢幕閱讀器習慣於快節奏的公告和快速導航，因此可能這個輔助功能可能不適用於視力正常的使用者。
使用 JavaScript 指令碼進行大頁面和 DOM 操作會導致螢幕閱讀器公告延遲。幾乎每個平臺(Jaws、NVDA、畫外音、旁白、Orca)都可以使用螢幕閱讀器進行一些檢測和測試，這是一個相對未開發的領域。
62. 您是否建立了連續監控
有一個WebPagetest 私人的例項總是有利於快速和無限的測試。但是，一個帶有自動效能迴歸警報報的連續監視工具 （如Sitespeed，Calibre 和SpeedCurve ） 將會給您提供更詳細的效能描述。設定您自己的使用者計時標記來度量和監視特定的業務度量。同時，考慮新增自動化效能迴歸警報來監控隨著時間而發生的變化。
使用 RUM 解決方案來監視效能隨時間的變化。對於自動化的類單元測試的負載測試工具，您可以使用 k6 指令碼 API。此外，可以瞭解下SpeedTracker， Lighthouse 和Calibre。
速效方案
此列表非常全面，按照這個清單完成所有優化可能需要一段時間。那麼，如果你只有1小時的時間來獲得重大改進，你會怎麼做？讓我們把這個清單歸結為 12個低掛的水果 。顯然，在開始之前和完成之後，測量結果是包括在3G和電纜連線上開始渲染時間和速度指數。
- 測量實際環境的體驗並設定適當的目標。一個好的目標是：第一次有意義的繪製 < 1 s，速度指數（Speed Index） < 1250，在慢速的 3G 網路上的互動 < 5s，對於重複訪問，TTI < 2s。優化渲染開始時間和互動時間。
- 為主模板準備關鍵CSS，並將其包含在
<head>頁面中。（您的預算為14 KB）。對於CSS / JS，檔案大小不超過170KB gzipped（0.7MB解壓縮）。。 - 儘可能多地減少程式碼量，優化，推遲和延遲載入指令碼，檢查輕量級備選方案並限制第三方指令碼的影響。
- 僅將遺留程式碼提供給舊版瀏覽器
<script type="module">。 - 嘗試重新組合CSS規則並測試體內 CSS。
- 新增資源提示以加快交付速度，使用
dns-lookup，preconnect，prefetch和preload。 - 分離 Web 字型並非同步載入它們，並在 CSS 中快速使用字型顯示渲染。
- 優化影象，並考慮將 WebP 用於關鍵頁面（例如登入頁面）。
- 檢查是否正確設定了 HTTP 快取頭和安全頭。
- 在伺服器上啟用
Brotli或Zopfli壓縮。 （如果都行不通，那就用Gzip壓縮。） - 如果HTTP / 2可用，請啟用 HPACK 壓縮，並開始監視混合內容警告。啟用 OCSP 裝訂。
- 如果可能，在服務工作快取中快取諸如字型，樣式，
JavaScript和影象之類的資源。
下載優化效能清單（PDF，Apple Pages）
結合這個效能優化清單，您就已經為任何型別的前端效能專案做好了準備。請隨意下載該清單的列印版PDF，以及一個可編輯的蘋果頁面文件，以定製您需要的清單：
- 下載清單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對這篇文章的校對，同樣也感謝我們出色的社群，分享了他們在效能優化工作中學習到的技術和經驗，供大家使用。你們真正的非常了不起！
寫在最後：也許這是你看的翻譯的最爛的文章（我不在乎，哈哈），開個玩笑。譯文肯定會有很多或大或小的錯誤，還請閱讀過的大佬多多幫忙指正，我會在看到評論的第一時間把內容更正過來，希望能把這篇譯文越來越完美化！最後，還是希望這份前端效能優化清單能給大家的工作帶來一定的幫助，讓大家寫的頁面效能能夠更上一層樓，工作更上一層樓，薪水更上一層樓！不甚感激！