網頁性能 CaseStudy：以 PressOne 首頁爲例

一般來講，工程師熟悉某個系統會只要搞清楚其數據結構和數據流轉過程基本足夠了，但從商業的角度來看，先後端工程師都應該關注的另外一個重要維度是系統性能，純技術角度來看性能能夠認爲是系統的響應速度（實際上還能夠認爲是執行效率等），而從用戶角度來看性能就是使用體驗。

網頁性能爲何重要？

頁面性能差的直接後果是用戶須要等待，而等待，尤爲是不肯定要多長時間的等待會給用戶帶來焦慮，爲了儘早的結束這種焦慮，除非訪問網頁是剛需，用戶一般會選擇直接關閉頁面。從實際數據來看，性能差是頁面高跳出率的重要緣由之一。

爲了搞清楚頁面性能對業務目標的影響，諸如 Yahoo、Google、Amazon 等科技公司都投入了很多資源去研究和優化，好比下面是 ThinkWithGoogle 運用神經網絡分析 2017 年 1100 萬廣告落地頁加載速度和頁面跳出率關係所獲得的結論：

結論顯而易見：越快越好，少便是多。

實際上，最近幾年來大型互聯網公司在頁面性能優化研發中產出了很多工具和文檔，方便工程師給網站作性能分析和優化。

其中文檔方面比較經典的當屬三本書：

• High Performance Websites，早期在 Yahoo 性能團隊工做的 Steve Souders 所著；
• Even Faster Websites，同上，在上冊的基礎上，列出了不少行之有效的細節優化手段；
• High Performance Browser Networks，Google 性能工程師 Ilya Grigorik 所著，能夠免費在線閱讀，固然若是想支持讀者，能夠選擇購買；

而工具則很是多，尤爲是 2015 年開始爆發的各類應用性能管理（APM，如 New Relic）工具，對工程師來講，比較經典易用的有：

• WebPageTest，能夠認爲是網頁性能分析工具中的 Vim 了，純開源項目，在全球都有節點，分析思路基本與 Yahoo 性能黃金法則相貼合；
• LightHouse，已經集成在 Chrome 開發者工具中，可以從現代 WEB 應用比較重要的幾個維度給出分析結果，好比加載速度、PWA、可用性、SEO 等，工具易用性、可得性都高於 WebPageTest，我的強烈建議；

網頁性能該怎麼衡量？

要清晰、準確的衡量網頁性能，咱們先要定義頁面性能，如何定義頁面性能？

1. 從後端角度看，能夠是首字節時間，即頁面發起請求到瀏覽器收到第一個響應字節的時間，英文 Time to First Byte；
2. 從瀏覽器角度看，能夠是頁面所依賴的所有靜態資源加載完成所須要的時間，即常說的徹底加載時間；
3. 從用戶角度看，能夠是敲回車鍵開始到看到頁面開始渲染的過程所需的時間，即常說的首次渲染時間，此概念還能夠細分，好比 WebPageTest 和 LightHouse 都有的 FirstMeaningfulPaint；

性能優化工做處在不一樣階段，或者業務場景不一樣，上面不一樣定義視角的適用性是不一樣的，也有把上面 3 種衡量方法加權求和獲得綜合的性能指數。

要想真正開始作優化，須要搞清楚從發起請求到瀏覽器渲染頁面並呈現給用戶的過程當中有哪些關鍵環節，好在現代瀏覽器提供的 Navigation Timing API 已經把這個過程標準化，方便咱們作性能指標的計算，以下圖：

舉例來講上面提到的首字節時間和徹底加載時間能夠用以下公式計算：

首字節時間 = responseStart - navigationStart

徹底加載時間 = loadEventEnd - navigationStart

至於首次渲染時間，準確的計算方式須要結合錄屏，篇幅緣由，這裏不作展開。

PressOne 首頁性能 CaseStudy

PressOne 是基於區塊鏈的內容分發公鏈，而 https://press.one 則是項目入口，目前功能還比較簡單，主要包括帳戶建立、用戶登陸、三方帳號綁定、用戶主頁、內容簽名等功能。首頁是任何網站的門戶，確保其訪問速度和體驗的重要性不言而喻，而 press.one 給筆者的初體驗除了新奇還包括慢，新用戶加載頁面平均須要 6s 以上，即便內容渲染以前有加載中提示，仍是有明顯的等待感。

雖然 press.one 是基於 angular 開發的單頁應用，適用於傳統頁面的大部分性能優化方法一樣適用，下面結合 LightHouse 對 press.one 首頁作簡單的性能分析，並列出行之有效的優化行動清單。

LightHouse 能夠獨立安裝使用，也能夠在 Google Chrome 中使用，由於集成到了開發者工具的 Audits 面板中，使用方法比較簡單，建議直接閱讀文檔。

下面是使用 Google Chrome 作性能診斷的結果：

百分制的性能指數結果是 18 分，3G 網絡下的徹底可交互時間長達 20S，一般到 10S 用戶基本都覺得網站壞掉了，可見優化的空間是巨大的。

LightHouse 列出的優化手段（Opportunities）和可能的緣由診斷（Diagnostics）都比較直觀：

• Enable text compression，啓用文本壓縮，針對 JS、CSS 等靜態資源是很是有效的優化手段，一般可節省 60% 以上，實施成本低，收益巨大，若是加上適當的緩存，能夠對重複訪問用戶更加友好；
• Reduce render-blocking stylesheets，減小阻塞渲染的樣式，須要把首屏渲染的樣式從總體樣式中剝離出來優先加載，實施成本偏高，收益中等；
• Unused CSS rules 是針對 CSS 文件的優化，減小傳輸實際上不須要的代碼，我仔細拔了下代碼，項目引入的 fontawesome 貌似確實沒用到，實際上這個庫卻不小，實施成本小，收益中等；
• Serve images in next-gen formats，使用更好的壓縮算法壓縮圖片，實施成本低，收益大；
• Proper size images，請求的圖片和使用尺寸對應，避免縮放，形成浪費，實施成本低，收益看狀況；

若是上面的優化手段都落地實施，從新評估性能指數大機率能夠達到及格線。

結合瀑布流分析，咱們也不難發現更進一步的優化點，關鍵資源加載鏈條（Critical Request Chain）太長了，以下圖：

要開始首次渲染（對應以下瀑布流圖右側藍色的豎線）除主文檔外，咱們還須要額外下載 5 個 JS 文件，1 個 CSS 文件：

關鍵資源加載鏈條太長的問題怎麼優化呢？

• 合併資源請求，好比 elliptic 和 keythereum 的三方依賴能夠直接合並，更激進的能夠和 polyfill 也合併；
• 合理使用懶加載，首次渲染不須要的資源作適當的拆分，SPA 和傳統頁面均可以實現，不讓非關鍵資源阻塞頁面首次渲染；
• 合理使用 CDN，由於一般 CDN 是地理位置離用戶更近的節點，能夠大大節省網絡傳輸的 RTT；

關鍵資源加載鏈條的問題解決以後，從新評估的性能指數大機率能達到 80 分。

那麼接下來呢？理論上看起來性能優化是無止境的，實際上任何一個領域花 20% 的時間能達到 80% 的目的（好比把頁面首次渲染時間降到 3s 之內），而後能夠收手去解決更重要的問題，固然時間容許的話，有追求的工程師會不斷的問本身，這是我能作到的極致麼？

繼續往下優化則要從頁面渲染的角度去考慮，畢竟咱們已經儘量快的把渲染頁面所需的各類資源交給了瀏覽器，怎麼讓它更快、更流暢的渲染出可交互的頁面是接下來須要重點考慮的。而渲染速度跟 DOM 節點的組織、JS 的組織、JS 和 DOM 交互的優化都有關係，篇幅緣由，能夠單獨寫文章介紹。

以上，但願對你有用。