網頁性能分析不徹底指南

前言

常常能在博客或者論壇上看到不少有關前端性能優化的文章，可是卻不多看到如何分析一個網頁的性能的文章。到底什麼樣的指標（或者說是標準）表明這個網頁性能好或者很差，經過什麼方式來獲得這些指標呢？所以，本文來說述下如何分析一個網頁的性能的好與差。本文用到的工具：chrome瀏覽器。下面咱們一一來看。

用RAIL模型評估運行時性能

首先要說明的是，運行性能是指你的網頁在運行的時候的性能，而不是加載的時候的性能。RAIL（Response-Animation-Idle-Load）模型是一種以用戶爲中心的性能模型，每一個網絡應用均具備與其生命週期相關的四個不一樣方面，且這些方面以不一樣的方式影響着性能。用官網圖來鎮壓一下：

alt RAIL模型

下面分別從四個方面闡述RAIL模型：

以用戶爲中心

任何網站的終極目標不是讓其在任何特定設備上都能運行很快，而是讓使用該網站的用戶滿意。用戶花在網站上的大多數時間不是等待加載，而是在使用過程當中等待響應。那麼怎樣評價延遲？讓咱們來看下面的表：

延遲	用戶反應
0~16毫秒	人們特別擅長跟蹤運動，若是動畫不流暢，他們就會對運動心生反感。 用戶能夠感知每秒渲染60幀的平滑動畫轉場，也就是每幀16毫秒（包括瀏覽器將新幀繪製到屏幕上所需的時間），那麼，留給應用大約只有10毫秒的時間來生成新幀。
0~100毫秒	在此時間內響應用戶操做，他們會以爲能夠當即得到結果。時間再長，操做與反應之間的鏈接就會中斷
100~300毫秒	用戶會遇到輕微可覺察的延遲。
300~1000毫秒	在此時間內，延遲感受像是任務天然和持續發展的一部分。對於網絡上的大多數用戶，加載頁面或更改視圖就像在完成一個任務。
1000+毫秒	超過1秒，用戶的注意力將離開他們正在執行的任務。
10,000+毫秒	用戶感到失望，可能會放棄任務，而且以後他們或許不會再回來。

響應（Response）: 在100毫秒之內響應

在用戶注意到滯後以前網站有100毫秒的時間能夠響應用戶輸入。這適用於大多數輸入，好比點擊按鈕、切換表單控件或是啓動動畫。可是不適用於觸摸拖動或滾動（由於觸摸拖動或滾動屬於動畫範疇）。若是網站未響應，操做與反應之間的鏈接就會中斷，用戶會注意到。所以，對於須要超過500毫秒才能完成的操做，須要始終提供反饋。

其實，有些動做能夠不等到用戶操做了才響應。網站可使用此100毫秒時間在後臺來執行其餘開銷大的工做，但前提是不影響用戶當前的操做。

動畫（Animation）: 在10毫秒內生成一幀（即達到60fps）

動畫不止是奇特的UI效果，例如滾動和觸摸拖動也屬於動畫類型。若是動畫幀率發生變化，用戶便會注意到。網站的目標是每秒生成60幀，每一幀必須完成如下全部步驟：

alt 渲染步驟

從純粹的數學角度而言，每幀的預算約爲16毫秒（1000毫秒/60幀=16.66毫秒/幀）。但將新幀渲染到屏幕上也是須要花費時間的，所以實際上瀏覽器只有10毫秒的時間來執行代碼，若是沒法符合此估算，幀率將降低，而且內容會在屏幕上抖動，也就是卡頓，會對用戶體驗產生負面影響。所以，若是可能，最好利用好100毫秒響應預先計算開銷大的工做，這樣網站就更有可能實現60fps的性能。

空閒（Idle）：最大程度增長空閒時間

能夠利用空閒來完成推遲的工做。例如：儘量減小預加載的數據，以便網站可以快速加載，並利用空閒時間加載剩餘數據。推遲的工做應分紅每一個耗時約50毫秒的多個塊。若是用戶開始交互，優先級最高的事項是響應用戶。要實現小於100毫秒的響應，應用必須在每50毫秒內將控制返回給主線程，這樣網站就能夠執行其餘像素管道、對用戶輸入做出反應等命令。

所以，以50毫秒塊工做既能夠完成任務，又能確保即時的響應。

加載（Load）：在1000毫秒之內呈現內容

在1秒鐘內加載網站，不然，用戶的注意力會分散，他們處理任務的感受會中斷。其實也無需在1秒內加載全部內容以讓用戶產生完整加載的感受。應該啓用漸進式渲染和在後臺執行一些工做，將非必需的加載推遲到空閒時間段再來加載。

關鍵RAIL指標彙總

要根據RAIL指標評估您的網站，可以使用Chrome的DevTools的performance面板（舊版本chrome能夠用TimeLine工具）記錄用戶操做（具體可見下面一節講解如何記錄性能數據）。而後根據這些關鍵RAIL指標檢查面板中的記錄時間。

RAIL步驟	關鍵指標	用戶操做
響應	輸入延遲時間（從點按到繪製）小於100毫秒。	用戶點按按鈕（例如打開導航）。
動畫	每一個幀的工做（從JS到繪製）完成時間小於16毫秒。	用戶滾動頁面，拖動手指（例如打開菜單）或看到動畫。 拖動時，應用的響應與手指位置有關（例如，拉動刷新、滑動輪播）。 此指標僅適用於拖動的持續階段，不適用於開始階段。
空閒	主線程JS工做分紅不大於50毫秒的塊。	用戶沒有與頁面交互，但主線程應足夠用於處理下一個用戶輸入。
加載	頁面能夠在1000毫秒內就緒。	用戶加載頁面並看到關鍵路徑內容。

利用chrome開發者工具執行運行時性能評估

下面的教程指引瞭如何利用chrome開發車工具(DevTools)的performance面板來分析運行時性能。

注意：下面的指引基於chrome 62版本，若是你用了其餘版本的chrome，其UI界面和特徵會有些許的不一樣。

準備工做

首先咱們打開官網提供的demo,請確保用瀏覽器隱身模式打開，以保證瀏覽器是在一個純淨的環境中。不然，若是你安裝了不少瀏覽器擴展，會對你性能分析的數據產生必定的干擾。接着打開DevTools，具體方法：Command+Option+I (Mac) or Control+Shift+I (Windows, Linux)。

alt 圖示

模擬手機CPU

手機設備具備比臺式機和筆記本更小的CPU頻率，不管什麼時候評估你的網頁，你都必須使用CPU限制來模擬網頁在手機設備上表現。

1. 在DevTools中，點擊Performance面板
2. 確保Screenshots複選框選中
3. 點擊Capture Settings（右上角的紅色設置圖標），展開其餘設置
4. CPU中選擇4x slowdown，DevTools會將CPU頻率限制到平時的四分之一。

alt 圖示

注意：若是測試其餘頁面，若是想測試在低端機上的性能，能夠選擇更低的倍數。這個只是爲了更好的演示，選擇了小一點的限制。

設置demo

1. 連續點擊Add 10按鈕，知道明顯能看到藍色方框比以前慢了，在高端機上可能要點擊20次左右。
2. 點擊Optimize按鈕，藍色方框應該移動地更快更平穩。
3. 點擊Un-Optimize按鈕，藍色的方塊移動得更慢更鬆弛。

   注意：若是你沒有觀察到明顯變慢，嘗試點擊幾回Subtract 10按鈕再嘗試前面步驟。不然若是你添加了太多的藍色方框，就會耗盡CPU資源。

記錄運行性能

當你頁面運行網頁的優化版本，藍色方框移動速度會變快。爲了更好的檢測出性能問題，咱們記錄網頁非優化的版本。

alt 圖示

1. 點擊Record按鈕（見圖示），DevTools會在頁面運行時捕獲性能指標。
2. 等待幾秒鐘
3. 點擊Stop按鈕（見圖示），DevTools中止記錄，並開始處理數據，隨後將處理結果顯示在performance面板中,以下圖

alt 圖示

分析結果

關鍵的性能指標是FPS，其值若是是60FPS，用戶體驗會很好，使用網站的感覺也是愉悅的。

FPS圖表

查看FPS圖表（圖中藍色方框框住的部分），若是看到了紅色長條，就表明幀率過低並已經影響到用戶體驗了。通常狀況下，綠色長條越高，FPS越高。

alt 圖示

CPU圖表

在FPS下面就是CPU圖表，圖表中的顏色和麪板底部的Summarytab中的顏色是匹配的。CPU顏色越豐富，表明在錄製過程當中CPU已經最大化了。若是這段豐富顏色的長條比較長，這就暗示網站應該想辦法讓CPU作更少的工做了，也就是說代碼邏輯須要作優化了。

alt 圖示

順便提一下的就是，不管鼠標移動到FPS,CPU或者NET圖表上，DevTools都會顯示在該時間節點上的屏幕截圖，將你的鼠標左右移動，能夠重放錄製畫面，這被稱爲擦洗，對於手動分析動畫進程頗有用。

alt 圖示

Frames部分

在Frames部分，若是將你的鼠標移動至綠色方塊部分，會顯示在該特定幀上的FPS值，此例中每幀可能遠低於60FPS的目標。的確，在這個例子中，這個頁面的性能不好而且能很明顯地被觀察到，可是在實際場景中，可能並非那麼的容易，因此，要用全部這些工具來進行綜合測量。

alt 圖示

尋找瓶頸（追根溯源）

如今你已經經過上面的各類方式瞭解並確信了這個網頁的性能很差，那麼爲何會差呢？是什麼致使它運行的這麼差的呢？

Summary Tab

當沒有選擇任何事件的時候，Summary tab顯示了網頁進程活動的分類。從圖中能夠看出，這個網頁花費了太多的時間在渲染（rendering）上了。所以，你的目標就是減小渲染工做花費的時間。

alt 圖示

Main部分

展開Main部分，DevTools將顯示主線程上的隨着時間推移的活動火焰圖。x軸表明隨時間推移的記錄，每一個長條表明一個事件，長條越寬，表明這個事件花費的時間越長。y軸表明調用堆棧，當你看到堆疊在一塊兒的事件時，意味着上層事件發起了下層事件。

alt 圖示

能夠經過單擊、鼠標滾動或者拖動來選中FPS,CPU或NET圖標中的一部分，Main部分和Summary Tab就會只顯示選中部分的錄製信息。注意Animation Frame Fired事件右上角的紅色三角形圖標，該紅色三角圖標是這個事件有問題的警告。

單擊Animation Frame Fired事件,Summary tab會顯示該事件相關的信息。

alt 圖示

注意reveal，點擊它，會高亮觸發Animation Frame Fired事件的事件。

alt 圖示

注意app.js:95,點擊它，會跳轉到source面板對應的源碼及其對應的行號。

當選中了一個事件以後，可使用鍵盤上的箭頭來選擇前面或者後面的事件

在Animation Frame Fired事件下面有一羣紫色的事件。若是把它們放寬一點，會看到幾乎每一個紫色事件的右上角都有紅色三角形圖標。點擊其中一個紫色事件（其實就是Layout事件），Summary tab會顯示該事件更詳細的信息。確實，這裏有一個強制reflow的警告。

alt 圖示

在Summary tab，點擊Recalculation Forced下面的app.js:71,DevTools會跳轉到觸發強制reflow的代碼行。

alt 圖示

這個代碼的問題在於，在動畫的每一幀都改變了藍色方塊的樣式並計算了每一個方塊在頁面的位置。由於樣式改變了，瀏覽器卻不肯定是不是每個方塊的位置都改變了，所以瀏覽器爲了計算方塊的位置，只能對方塊從新佈局。能夠查看Avoid forced synchronous layouts這篇文來了解如何避免大型、複雜的佈局和佈局抖動。

更多的時間線事件參考，請點擊這裏

利用chrome開發者工具執行加載性能評估

1. 打開你要評估的頁面
2. 打開performance面板
3. 點擊Start profiling and reload page（圖中藍色方框框住部分），DevTools在頁面從新加載時記錄性能指標，而後在加載完成後幾秒鐘自動中止錄製。
4. 其餘分析方式同上面的運行時性能評估。

alt 圖示

如同評估運行時性能同樣設置了CPU限制，你也能夠在設置裏面設置network控制，來調整你想要的網絡速度環境。

總結

可使用chrome瀏覽器DevTools中的Performance面板來獲得網頁的加載性能和運行時的性能數據，根據上文介紹的分析方法，結合RAIL模型來評估網頁性能的好與差。這是一個頗有效的方法。具體如何提升網頁的性能呢？這又是一個大課題，相信網上也有很多與之相關的博文能夠參考，筆者後續有時間也出相關博文。

參考文獻

Get Started With Analyzing Runtime Performance