（譯）2019年前端性能優化清單 — 下篇

• （譯）2019年前端性能優化清單 — 上篇
• （譯）2019年前端性能優化清單 — 中篇
• （譯）2019年前端性能優化清單 — 下篇

目錄

• 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. 您是否創建了連續監控
• 速效方案
• 動身吧！

HTTP/2

52. 遷移到HTTPS，而後打開HTTP / 2

隨着 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），與資源的數量成線性關係，所以頁面中若是包含數以百計的資源將會形成瀏覽器性能損失。

要想能達到 HTTP/2 的最佳使用效果，能夠考慮使用 漸進加載CSS, 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優先級 進行了相似的研究。

TLS還快嗎?容許您在切換到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。

使用 Lighthouse CI 將 可訪問性，性能和SEO分數 集成到 Travis 設置中，能夠突出顯示新功能對全部貢獻開發人員的性能影響。

60. 您是否在代理瀏覽器和傳統瀏覽器中測試過

僅僅在 Chrome 和 Firefox 瀏覽器進行測試是不夠的。咱們還須要瞭解網站在代理瀏覽器和舊版瀏覽器中的工做方式。例如，UC 瀏覽器 和 Opera Mini ，這些瀏覽器 在亞洲佔有很大的市場份額 （ 高達35％ ）。測量您感興趣的國家/地區的 平均互聯網速度，以免出現重大意外狀況。測試網絡節流，並仿真一個高 DPI 設備。BrowserStack 很不錯，但也要在實際設備上測試。

k6 容許您編寫單元測試 - 相似的性能測試。

61. 您是否測試了輔助功能

當瀏覽器開始加載頁面時，它構建一個DOM，若是有像屏幕閱讀器這樣的輔助技術在運行，它還會建立一個可訪問性樹。而後屏幕閱讀器會經過查詢可訪問性樹來檢索信息並使其對用戶可用 —— 這有時是默認的，有時是按需的。

咱們所說的快速交互時間，一般指的是用戶經過點擊連接和按鈕與頁面交互的速度。當屏幕閱讀器的上下文略有不一樣的時候，快速交互時間意味着屏幕閱讀器能夠在頁面顯示導航，到屏幕閱讀器上的用戶能夠用鍵盤與頁面進行交互所需的時間。

萊內·沃森（LéonieWatson） 在 易訪問性性能方面 作了一次大開眼界的 演講，特別是慢加載對屏幕閱讀器發佈延遲的影響。屏幕閱讀器習慣於快節奏的公告和快速導航，所以可能這個輔助功能可能不適用於視力正常的用戶。

使用 JavaScript 腳本進行大頁面和 DOM 操做會致使屏幕閱讀器公告延遲。幾乎每一個平臺(Jaws、NVDA、畫外音、旁白、Orca)均可以使用屏幕閱讀器進行一些檢測和測試，這是一個相對未開發的領域。

62. 您是否創建了連續監控

有一個 WebPagetest 私人的實例老是有利於快速和無限的測試。可是，一個帶有自動性能迴歸警報報的連續監視工具 （如 Sitespeed， Calibre 和 SpeedCurve ） 將會給您提供更詳細的性能描述。設置您本身的用戶計時標記來度量和監視特定的業務度量。同時，考慮添加自動化性能迴歸警報來監控隨着時間而發生的變化。

使用 RUM 解決方案來監視性能隨時間的變化。對於自動化的類單元測試的負載測試工具，您可使用 k6 腳本 API。此外，能夠了解下SpeedTracker，Lighthouse 和 Calibre。

速效方案

此列表很是全面，按照這個清單完成全部優化可能須要一段時間。那麼，若是你只有1小時的時間來得到重大改進，你會怎麼作？讓咱們把這個清單歸結爲 12個低掛的水果。顯然，在開始以前和完成以後，測量結果是包括在3G和電纜鏈接上開始渲染時間和速度指數。

1. 測量實際環境的體驗並設定適當的目標。一個好的目標是：第一次有意義的繪製 < 1 s，速度指數（Speed Index） < 1250，在慢速的 3G 網絡上的交互 < 5s，對於重複訪問，TTI < 2s。優化渲染開始時間和交互時間。
2. 爲主模板準備關鍵CSS，並將其包含在 <head> 頁面中。（您的預算爲14 KB）。對於CSS / JS，文件大小不超過 170KB gzipped（0.7MB解壓縮）。。
3. 儘量多地減小代碼量，優化，推遲和延遲加載腳本，檢查輕量級備選方案並限制第三方腳本的影響。
4. 僅將遺留代碼提供給舊版瀏覽器 <script type="module">。
5. 嘗試從新組合CSS規則並測試體內 CSS。
6. 添加資源提示以加快交付速度，使用 dns-lookup，preconnect，prefetch 和 preload。
7. 分離 Web 字體並異步加載它們，並在 CSS 中快速使用字體顯示渲染。
8. 優化圖像，並考慮將 WebP 用於關鍵頁面（例如登陸頁面）。
9. 檢查是否正確設置了 HTTP 緩存頭和安全頭。
10. 在服務器上啓用 Brotli 或 Zopfli 壓縮。 （若是都行不通，那就用 Gzip 壓縮。）
11. 若是HTTP / 2可用，請啓用 HPACK 壓縮，並開始監視混合內容警告。啓用 OCSP 裝訂。
12. 若是可能，在服務工做緩存中緩存諸如字體，樣式，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對這篇文章的校對，一樣也感謝咱們出色的社區，分享了他們在性能優化工做中學習到的技術和經驗，供你們使用。大家真正的很是了不得！

寫在最後： 也許這是你看的翻譯的最爛的文章（我不在意，哈哈），開個玩笑。譯文確定會有不少或大或小的錯誤，還請閱讀過的大佬多多幫忙指正，我會在看到評論的第一時間把內容更正過來，但願能把這篇譯文愈來愈完美化！最後，仍是但願這份前端性能優化清單能給你們的工做帶來必定的幫助，讓你們寫的頁面性能可以更上一層樓，工做更上一層樓，薪水更上一層樓！不甚感激！