前端性能優化之利用 Chrome Dev Tools 進行頁面性能分析

背景

咱們常用 Chrome Dev Tools 來開發調試，可是不多知道怎麼利用它來分析頁面性能，這篇文章，我將詳細說明怎樣利用 Chrome Dev Tools 進行頁面性能分析及性能報告數據如何解讀。

分析面板介紹

上圖是 Chrome Dev Tools 的一個截圖，其中，我認爲能用於進行頁面性能快速分析的主要是圖中圈出來的幾個模塊功能，這裏簡單介紹一下：

• Network : 頁面中各類資源請求的狀況，這裏能看到資源的名稱、狀態、使用的協議(http1/http2/quic...)、資源類型、資源大小、資源時間線等狀況
• Performance : 頁面各項性能指標的火焰圖，這裏能看到白屏時間、FPS、資源加載時間線、longtask、內存變化曲線等等信息
• Memory : 能夠記錄某個時刻的頁面內存狀況，通常用於分析內存泄露
• JavaScript Profiler : 能夠記錄函數的耗時狀況，方便找出耗時較多的函數
• Layers : 展現頁面中的分層狀況

分析步驟說明

首先，咱們在分析的時候，建議使用隱身模式打開頁面，排除一些插件等因素對頁面性能狀況的影響。而後，咱們把頁面緩存勾選去掉，要測 disable cache 的狀況，再把網絡狀況調整一下，咱們用電腦打開頁面的時候通常都連着 wifi 等，要更真實一些去測頁面的性能，仍是把網絡調到 3G 等狀況比較好，如圖：

調整好以後，咱們切到 Performance 面板，這裏先說明一下一些按鈕的做用：

上圖，從左到右分別表明的是：

1. 手動開始記錄，開始後須要手動結束
2. 自動重啓頁面，並記錄整個頁面加載的過程。這個是最經常使用的，通常大概分析頁面性能的時候都是點這個就夠了
3. 清除性能錄製的記錄
4. 上傳頁面性能錄製的數據
5. 下載頁面性能錄製的數據
6. 選擇要展現的性能記錄。你可能進行了屢次分析，這裏能夠切換去看每次的結果
7. 是否捕捉頁面加載過程的截圖，這個通常都要勾選
8. 是否記錄內存變化，這個通常都要勾選
9. 垃圾回收，點擊了即進行一次垃圾回收

這裏，我以京東的一個頁面爲例,勾選 disable cache,網絡狀況爲 Fast 3G，來講明一下，應該如何理解性能結果，找出優化點。

從網絡面板分析

咱們來看看網絡面板，看看都有哪些信息。以下圖所示：

從圖中能夠看出，頁面中有的一些性能優化手段有：

1. 頁面直出，輸入https://wq.jd.com/wxportal/index_v6 ,頁面加載回來的 document 就是一個渲染好的 html 頁面
2. 圖片優化，部署在不一樣的CDN域名下，用webp/dpg等格式圖片，圖片切割等
3. http 協議有部分採用 http2，多路複用，加快資源加載
4. 小 logo 使用base42來處理
5. 按需加載，菜單先加載第一屏的圖標，滑動到第二屏時再加載第二屏的圖標

而從圖片，我的認爲，還能夠考慮用上的一些性能優化手段有：

1. html 的大小爲138kb,Content Download的時間爲七百多毫秒，感受能夠拆分一下頁面，非一二屏的內容分開加載。
2. TTFB(Time To First Byte)爲五百多毫秒,在下載第一個字節以前等待的時間太久，不過這裏主要是用戶網絡狀況影響，能夠作的比較少。如DNS解析優化，減小後端服務處理時間等
3. 合併雪碧圖，大輪播圖下面的菜單分類那裏的圖標，能夠用一張雪碧圖來集合這些圖標
4. 頂部輪播圖，在首次加載時，能夠先加載第一幀的圖片，後面幾幀延後一下
5. 圖片較多，能夠的話，都用 http2 協議

從性能面板分析

切到 Performance 面板，點擊自動重啓頁面，並記錄整個頁面加載的過程，而後來分析結果～​

網絡&&白屏

性能面板，有不少不少的參數，咱們要看一些比較常見的。首先看白屏時間和網絡加載狀況，以下圖：

上圖，咱們能夠看幾點信息：

1. 本次頁面加載的白屏時間約爲 1000 ms
2. FPS 曲線沒有標紅，若是有不少標紅的則說明頁面存在渲染卡頓多的地方
3. 從網絡資源加載狀況來看，圖片沒有啓用 http2，所以每次能夠同時加載的圖片數有限，未被加載的圖片有等待過程
4. 資源的加載時間也能夠看到，好比輪播的背景圖加載了近 700 毫秒，時間有點長

另外，咱們能夠看一下資源加載有沒有空白期，雖然上圖沒有，可是若是資源加載之間存在空白期，說明沒有充分利用資源加載的空閒時間，能夠調整一下。

火焰圖

火焰圖，主要在 Main 面板中，是咱們分析具體函數耗時最常看的面板，咱們來看一下，如圖：

首先，面板中會有不少的 Task，若是是耗時長的 Task，其右上角會標紅(圖中沒有，說明頁面首屏的邏輯處理分配得還不錯)，這個時候，咱們能夠選中標紅的 Task (這裏就隨手選中一個)，而後放大(選中，滑動鼠標可放大)，看其具體的耗時點。

放大後，這裏能夠看到都在作哪些操做，哪些函數耗時了多少,這裏代碼有壓縮，看到的是壓縮後的函數名。而後咱們點擊一下某個函數，在面板最下面，就會出現代碼的信息，是哪一個函數，耗時多少，在哪一個文件上的第幾行等。這樣咱們就很方便地定位到耗時函數了。

還能夠橫向切換 tab ，看它的調用棧等狀況，更方便地找到對應代碼。具體你們能夠試試～

時間線&&內存狀況

在 Timings 的區域，咱們能夠看到本次加載的一些關鍵時間，分別有：

• FCP: First Contentful Paint
• LCP: Largest Contentful Paint
• FMP: First Meaningful Paint
• DCL: DOMContentLoaded Event
• L: Onload Event

咱們能夠選區(選擇從白屏到有內容的區域，表明本次的頁面加載過程)，能夠對照着看一下上面的時間，截圖以下：

另外，咱們能夠看到頁面中的內存使用的狀況，好比 JS Heap(堆)，若是曲線一直在增加，則說明存在內存泄露，從圖中能夠看出，至關長的一段時間，內存曲線都是沒有降低的，這裏是有發生內存泄露的可能的，在 Onload 以後，內存才獲得釋放。更多內存泄露產生的緣由及分析方法，能夠參照個人這篇文章《Chrome 瀏覽器垃圾回收機制與內存泄漏分析》

最下方就是頁面的一個整理耗時概況，若是 Scripting 時間過長，則說明 js執行的邏輯太多，能夠考慮優化js，若是渲染時間過長，則考慮優化渲染過程，若是空閒時間過多，則能夠考慮充分利用起來，好比把一些上報操做放到頁面空閒時間再上報等。

其餘面板

以上就是性能面板能夠看的一些信息。另外，咱們能夠藉助 Layers面板來查看頁面分層狀況的3D視圖，Rendering面板(點擊more tools->Rendering便可打開)，勾選Layer Bordersk能夠看到複合層、RenderLayer區域，能夠幫助分析動畫卡頓、是否開啓GPU加速等問題，而 Memory 面板 和 JavaScript Profiler 面板主要是分析內存泄露的，這裏就不說了，能夠看我另外一篇文章《Chrome 瀏覽器垃圾回收機制與內存泄漏分析》

用Audits工具分析

Audits 其實就是 LightHouse，LightHouse 是Google開源的一個自動化測試工具，它經過一系列的規則來對網頁進行評估分析，最終給出一份評估報告。它的面板是這樣的：

總體狀況

Audits主要從5個方面來給網頁打分，固然你也能夠去掉某些方面的評估。在選擇了設備、評估方面、網絡狀況等選項後，點擊 Run Audits ,咱們將會獲得一份報告。

上圖是一個整體報告，能夠看出，這個頁面的性能不太合格。固然一次的測試也說明不了什麼問題，只能作個參考。咱們看它的性能指標分別有：

• First Contentful Paint：內容首次開始繪製。
• First Meaningful Paint：能夠簡單理解爲用戶看到網頁主要內容的時間，分數越低，頁面顯示其主要內容的速度就越快。圖中例子，網頁首次有效繪製時間爲2.5s。
• Speed Index：速度指標是一個頁面加載性能指標，向你展現明顯填充頁面內容的速度，此指標的分數越低越好。
• First CPU Idle：首次 CPU 空閒時間
• Time to Interactive：可互動時間，頁面中的大多數網絡資源完成加載而且CPU在很長一段時間都很空閒的所需的時間。此時能夠預期cpu很是空閒，能夠及時的處理用戶的交互操做。
• Max Potential First Input Delay：最大的輸入延遲時間，輸入響應能力對用戶如何看待你應用的性能起着關鍵做用。應用有 100 毫秒的時間響應用戶輸入。若是超過此時間，用戶就會認爲應用反應遲緩。

這些時間，均可以點擊圖中紅框切換展現方式，會附上對應的時間解釋，而後能夠點擊 Learn more 來查看詳細的指標介紹。在文檔中，每一項指標都會明確的分爲三個部分：爲何說此審查很是重要；如何經過此審查；如何實現此審查；

性能指標優化建議解讀

性能建議主要分爲3類， Opportunities 可優化項、手動診斷項、經過的審查項。本次的例子以下圖：

圖中的每一項均可以展開來看明細解釋，其中：

可優化項有2個建議：

1. 延遲會阻塞渲染的資源加載，這裏是一個 navfoot.6bf68af7.css
2. 延遲視口外的圖片加載，這裏列舉了沒必要要加載的圖片(和我上文提的優化建議一致，哈哈)

這項裏面的內容指的是LightHouse發現的一些能夠直接優化的點，你能夠對應這些點來進行優化。

手動診斷項有6個建議：

1. 最小化主線程工做
2. 減小JavaScript執行時間
3. 避免DOM太大
4. 經過有效的緩存策略緩存一些靜態資源
5. 避免連接關鍵請求
6. 保持低請求數量和小傳輸大小

這些項目表示LightHouse並不能替你決定當前是好是壞，可是把詳情列出來，由你手動排查每一個項目的狀況

經過的審查項

這裏列出的都是作的好的地方，本文例子共有16條，不過即便作的好，依然值得咱們進去仔細看一下，由於像全部條目同樣，這裏的每一個條目也有一個showmore，咱們能夠點進去仔細學習背後的知識和原理！

Accessibility輔助功能

輔助功能指的是那些可能超出"普通"用戶範圍以外的用戶的體驗，他們以不一樣於你指望的方式訪問你的網頁或進行交互，本文的例子建議以下圖：

輔助功能類別測試屏幕閱讀器的能力和其餘輔助技術是否能在頁面中正常工做。例如：按元素來使用屬性，標籤使用是否規範，img 標籤是否缺乏 alt 屬性，可辨別的元素命名等等。這一項咱們不展開講，可是仍是建議你們按照審計建議修改一下網頁。

其餘幾項，本文的例子最佳實踐評分挺高的，而例子不支持PWA，也不須要考慮SEO，這裏就不展開說明了，有對應需求的能夠本身詳細看看便可。

總結

最後總結一下，咱們利用Chrome Dev Tools 進行頁面性能分析有如下指標能夠參考：

• 從網絡面板分析
• 從性能面板分析
• 從Memory面板等分析內存泄露
• 用Audits工具分析

而這些分析方法，本文都詳細寫了。能夠認真看看～

姊妹篇推薦

• 前端性能優化之自定義性能指標及上報方法詳解

最後

• 歡迎加我微信(winty230)，拉你進技術羣，長期交流學習...
• 歡迎關注「前端Q」,認真學前端，作個有專業的技術人...