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

時間  2019-11-06
標籤 前端 性能 優化 年度 總結 第六 部分 欄目 系統性能 简体版
原文   原文鏈接

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

內容目錄

HTTP/2

52. 遷移到 HTTPS，而後啓用 HTTP/2

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

HTTP/2

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

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

53. 合適地部署 HTTP/2

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

一方面，你可能想避免資源全都合併在一塊兒，而是把所有的接口分割成許多小的模塊，把它們壓縮爲構建進程的一部分，經過 「偵查」途徑引用並並行加載它們。一個文件的改變不須要從新加載所有樣式或 JavaScript 。它還壓縮解析時間並使每一個頁面保持少許的資源負載。webpack

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

漸進式 CSS 加載

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

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

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

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 速度快嗎？

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 倍。」

拉取請求（pull request）檢查很是有必要

經過使用 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 文檔。

若是你須要更多選擇，你也能夠查看 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 對這篇文章的審閱，同時也感謝咱們無與倫比的社區，你們會分享從工做學到的，對每一個人都有用的優化技術和課程。大家真的是太棒了！

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

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

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程