前言
經常能在部落格或者論壇上看到很多有關前端效能優化的文章，但是卻很少看到如何分析一個網頁的效能的文章。到底什麼樣的指標（或者說是標準）代表這個網頁效能好或者不好，通過什麼方式來得到這些指標呢？因此，本文來講述下如何分析一個網頁的效能的好與差。本文用到的工具：chrome瀏覽器。下面我們一一來看。
用RAIL模型評估執行時效能
首先要說明的是，執行效能是指你的網頁在執行的時候的效能，而不是載入的時候的效能。RAIL（Response-Animation-Idle-Load）模型是一種以使用者為中心的效能模型，每個網路應用均具有與其生命週期相關的四個不同方面，且這些方面以不同的方式影響著效能。用官網圖來鎮壓一下：
下面分別從四個方面闡述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幀，每一幀必須完成以下所有步驟：
從純粹的數學角度而言，每幀的預算約為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)。
模擬手機CPU
手機裝置具有比桌上型電腦和筆記本更小的CPU頻率，無論何時評估你的網頁，你都必須使用CPU限制來模擬網頁在手機裝置上表現。
- 在DevTools中，點選
Performance皮膚 - 確保
Screenshots核取方塊選中 - 點選
Capture Settings（右上角的紅色設定圖示），展開其他設定 - CPU中選擇
4x slowdown，DevTools會將CPU頻率限制到平時的四分之一。
注意：如果測試其他頁面，如果想測試在低端機上的效能，可以選擇更低的倍數。這個只是為了更好的演示，選擇了小一點的限制。
設定demo
- 連續點選
Add 10按鈕，知道明顯能看到藍色方框比之前慢了，在高階機上可能要點選20次左右。 - 點選
Optimize按鈕，藍色方框應該移動地更快更平穩。 - 點選
Un-Optimize按鈕，藍色的方塊移動得更慢更鬆弛。注意：如果你沒有觀察到明顯變慢，嘗試點選幾次
Subtract 10按鈕再嘗試前面步驟。否則如果你新增了太多的藍色方框，就會耗盡CPU資源。
記錄執行效能
當你頁面執行網頁的優化版本，藍色方框移動速度會變快。為了更好的檢測出效能問題，我們記錄網頁非優化的版本。
- 點選
Record按鈕（見圖示），DevTools會在頁面執行時捕獲效能指標。 - 等待幾秒鐘
- 點選
Stop按鈕（見圖示），DevTools停止記錄，並開始處理資料，隨後將處理結果顯示在performance皮膚中,如下圖
分析結果
關鍵的效能指標是FPS，其值如果是60FPS，使用者體驗會很好，使用網站的感受也是愉悅的。
FPS圖表
檢視FPS圖表（圖中藍色方框框住的部分），如果看到了紅色長條，就代表幀率太低並已經影響到使用者體驗了。一般情況下，綠色長條越高，FPS越高。
CPU圖表
在FPS下面就是CPU圖表，圖表中的顏色和皮膚底部的Summarytab中的顏色是匹配的。CPU顏色越豐富，代表在錄製過程中CPU已經最大化了。如果這段豐富顏色的長條比較長，這就暗示網站應該想辦法讓CPU做更少的工作了，也就是說程式碼邏輯需要做優化了。
順便提一下的就是，無論滑鼠移動到FPS,CPU或者NET圖表上，DevTools都會顯示在該時間節點上的螢幕截圖，將你的滑鼠左右移動，可以重放錄製畫面，這被稱為擦洗，對於手動分析動畫程式很有用。
Frames部分
在Frames部分，如果將你的滑鼠移動至綠色方塊部分，會顯示在該特定幀上的FPS值，此例中每幀可能遠低於60FPS的目標。的確，在這個例子中，這個頁面的效能很差並且能很明顯地被觀察到，但是在實際場景中，可能並不是那麼的容易，所以，要用所有這些工具來進行綜合測量。
尋找瓶頸（追根溯源）
現在你已經通過上面的各種方式瞭解並確信了這個網頁的效能不好，那麼為什麼會差呢？是什麼導致它執行的這麼差的呢？
Summary Tab
當沒有選擇任何事件的時候，Summary tab顯示了網頁程式活動的分類。從圖中可以看出，這個網頁花費了太多的時間在渲染（rendering）上了。因此，你的目標就是減少渲染工作花費的時間。
Main部分
展開Main部分，DevTools將顯示主執行緒上的隨著時間推移的活動火焰圖。x軸代表隨時間推移的記錄，每個長條代表一個事件，長條越寬，代表這個事件花費的時間越長。y軸代表呼叫堆疊，當你看到堆疊在一起的事件時，意味著上層事件發起了下層事件。
可以通過單擊、滑鼠滾動或者拖動來選中FPS,CPU或NET圖示中的一部分，Main部分和Summary Tab就會只顯示選中部分的錄製資訊。注意Animation Frame Fired事件右上角的紅色三角形圖示，該紅色三角圖示是這個事件有問題的警告。
單擊Animation Frame Fired事件,Summary tab會顯示該事件相關的資訊。
注意reveal，點選它，會高亮觸發Animation Frame Fired事件的事件。
注意app.js:95,點選它，會跳轉到source皮膚對應的原始碼及其對應的行號。
當選中了一個事件之後，可以使用鍵盤上的箭頭來選擇前面或者後面的事件
在Animation Frame Fired事件下面有一群紫色的事件。如果把它們放寬一點，會看到幾乎每個紫色事件的右上角都有紅色三角形圖示。點選其中一個紫色事件（其實就是Layout事件），Summary tab會顯示該事件更詳細的資訊。確實，這裡有一個強制reflow的警告。
在Summary tab，點選Recalculation Forced下面的app.js:71,DevTools會跳轉到觸發強制reflow的程式碼行。
這個程式碼的問題在於，在動畫的每一幀都改變了藍色方塊的樣式並計算了每個方塊在頁面的位置。因為樣式改變了，瀏覽器卻不確定是否是每一個方塊的位置都改變了，因此瀏覽器為了計算方塊的位置，只能對方塊重新佈局。可以檢視Avoid forced synchronous layouts這篇文來了解如何避免大型、複雜的佈局和佈局抖動。
更多的時間線事件參考，請點選這裡
利用chrome開發者工具執行載入效能評估
- 開啟你要評估的頁面
- 開啟performance皮膚
- 點選
Start profiling and reload page（圖中藍色方框框住部分），DevTools在頁面重新載入時記錄效能指標，然後在載入完成後幾秒鐘自動停止錄製。 - 其他分析方式同上面的執行時效能評估。
如同評估執行時效能一樣設定了CPU限制，你也可以在設定裡面設定network控制，來調整你想要的網路速度環境。
總結
可以使用chrome瀏覽器DevTools中的Performance皮膚來得到網頁的載入效能和執行時的效能資料，根據上文介紹的分析方法，結合RAIL模型來評估網頁效能的好與差。這是一個很有效的方法。具體如何提高網頁的效能呢？這又是一個大課題，相信網上也有不少與之相關的博文可以參考，筆者後續有時間也出相關博文。