使用Chrome DevTools的Timeline分析頁面性能

原文地址：http://horve.github.io/2015/10/26/timeli...

隨着webpage能夠承載的表現形式更加多樣化，經過webpage來實現更多交互功能，構建web應用程序已經成爲不少產品的首要選擇。這種方式擁有很是明顯的優點：跨平臺、開發便捷、便於部署和維護等等，但隨着功能的不斷積累，web應用程序也會變得愈來愈複雜。可是，咱們仍然想要在webpage支持豐富的呈現形式的同時，讓頁面效果可以達到>=60fps(幀)/s的刷新頻率以免出現卡頓，就須要咱們使用一些比較直觀的方式來分析衡量頁面的性能問題，爲性能優化方案提供依據。

爲何是60fps?
咱們的目標是保證頁面要有高於每秒60fps(幀)的刷新頻率，這和目前大多數顯示器的刷新率相吻合(60Hz)。若是網頁動畫可以作到每秒60幀，就會跟顯示器同步刷新，達到最佳的視覺效果。這意味着，一秒以內進行60次從新渲染，每次從新渲染的時間不能超過16.66毫秒。

需求大致明確，就是要找到頁面執行過程當中的性能瓶頸。而Chrome DevTools的Timeline則正是用來記錄和分析應用在運行時全部的活動狀況，它是用來排查應用性能瓶頸的最佳工具。

下圖是Timeline面板的預覽效果：

Tips:爲了不瀏覽器插件對分析過程產生影響，建議在隱身模式下進行分析。

Timeline工具欄介紹

Timeline工具會詳細檢測出在Web應用加載的過程當中時間花費狀況的概覽，包括下載資源、處理DOM事件、頁面佈局渲染、向屏幕繪製元素等。你能夠經過分析Timeline獲得的事件、框架和實時的內存用量，找出應用的性能問題。

在分析頁面前，須要首先開啓錄製功能，記錄頁面的操做和渲染記錄。如上圖，左上角的灰色圓點就是錄製按鈕，點擊後會變成紅色，而後在頁面上進行相關操做後再次按下變成灰色完成錄製，這樣就完成了一次對操做及加載渲染的記錄過程，隨後Timeline就會開始分析操做過程當中的各項性能參數。

Timeline同時提供了兩種查看模式：「事件模式(Event Mode)」和「幀模式(Frame Mode)」。如上圖箭頭所示。

事件模式：顯示從新渲染的各類事件花費的時間。
幀模式：顯示每一幀的時間花費狀況。

事件模式 (Event Mode)

若是咱們的一個頁面執行效率不高，咱們必需要搞清楚致使頁面性能低下的緣由，究竟是javascript執行出了問題，仍是頁面渲染出了問題。要了解這裏面的執行細節，咱們可使用「事件模式」來進行分析。首先咱們須要錄製一些須要被分析的操做，錄製結束後進入事件模式預覽Timeline。下圖是獲得的事件模式的視圖：

在上圖中，不一樣的顏色表示不一樣的事件。一種顏色的區塊越長，說明在處理該事件的耗時就越長。單擊某一區塊，能夠在下面的Summary概要中看到詳細的事件處理過程及耗時分佈。

藍色(Loading)：網絡通訊和HTML解析
黃色(Scripting)：JavaScript執行
紫色(Rendering)：樣式計算和佈局，即重排
綠色(Painting)：重繪
灰色(other)：其它事件花費的時間
白色(Idle)：空閒時間

在顯示的記錄中，瀏覽器也會爲在檢測過程當中發現的一些可能致使性能問題的過程進行標註，在Mode View視圖區域，可能會出現一些紅色的區塊段，這些紅色的區塊段代表，在對應的時間上執行的事件可能存在性能問題，而在對應的Main Thread視圖區域，事件區塊的右上角會出現紅色的小三角，點擊當前區塊，在下面的Summary概要區域內會給出詳細的警告內容以及腳本可能出現問題的行數，以下圖，瀏覽器提示「強制同步佈局可能會致使性能瓶頸」：

此外，在關閉Event Mode後，還能夠看到Record Detail視圖，詳細列出一次記錄中各種事件的詳細內容。

Record Detail視圖區域的左側是事件標題，右側是對應的時間線。點擊每一條時間標題能夠看到更多信息，如事件發生在腳本的哪一行等。若是你只對某一個時間段內的某些操做感興趣，能夠經過移動時間軸的始末位置來選擇要瀏覽的區域：

幀模式 (Frame Mode)

幀模式從頁面渲染性能的角度提供了數據支撐，一個柱狀「frame」表示渲染過程當中的一幀，也就是瀏覽器爲了渲染單個內容塊而必需要作的工做，包括：執行js，處理事件，修改DOM，更改樣式和佈局，繪製頁面等。

如前文所述，咱們的目標是保證頁面要有高於每秒60fps(幀)的刷新頻率，這樣就能保證頁面有高流暢度的渲染。

中在Frame視圖中有兩條貫穿該視圖的橫線，分別標識出60FPS和30FPS的基準，按照前面提到的16.66ms的計算方式，咱們能夠理解爲分別標識了16.6ms和33.3ms兩個時間點。下面的一條是60FPS，低於這條線，能夠達到每秒60幀；上面的一條是30FPS，低於這條線，能夠達到每秒30次渲染。若是色柱都超過30FPS，這個網頁就有性能問題了。

圖中幀柱的高度表示了該幀的總耗時，幀柱中的顏色分別對應該幀中包含的不停類型的事件。每一幀柱的高度越低越好，上圖是藝龍PC首頁www.elong.com的幀渲染圖，從圖中能夠看出，在進行某些幀的渲染時，幀的渲染頻率低於30FPS/s，第二幀和第三幀就大幅低於30fps(幀柱高度高於30fps標準線)，在實際瀏覽器渲染中就有可能出現卡頓。對相關的幀進行分析時，能夠點擊其中某一幀查看渲染詳情，也能夠選擇某個區域的幾個幀查看渲染詳情。而要找出可能影響性能的緣由，點擊當前問題幀，在Summary面板及Record Detail視圖中的詳細信息中進行逐條分析。

你可能注意到了在幀柱上存在灰色區域和空白區域,它們分別表明：
灰色區塊：那些沒有被DevTools感知到的活動
空白區塊：顯示刷新週期（display refresh cycles）中的空閒時間段

點擊某一個幀柱還能夠獲得該幀的詳細記錄數據：

Warning: 警告信息
ScreenShot: 當前選中幀的渲染截屏
Duration: 該記錄及其子記錄的總耗時
FPS: 當前幀的渲染頻率
CPU Time: CPU耗時
Aggregated Time: 合計耗時分佈

總結

發現問題是解決問題的第一步，chrome瀏覽器的TimeLine工具能夠很好地輔助咱們分析頁面的性能瓶頸，提供詳細全面的分析數據，爲咱們進行性能優化提供數據依據。固然，TimeLine中有用的功能還有不少，好比Memery Mode, Screen Shot等，使用技巧多種多樣，在這裏主要介紹瞭如何去記錄一段渲染過程，如何去使用Event Mode和Frame Mode去查看並分析獲得性能指標，後續若是有新的體會和發現，還會再作記錄~

TimeLine中的事件彙總

Loading事件

事件	描述
Parse HTML	瀏覽器執行HTML解析
Finish Loading	網絡請求完畢事件
Receive Data	請求的響應數據到達事件，若是響應數據很大（拆包），可能會屢次觸發該事件
Receive Response	響應頭報文到達時觸發
Send Request	發送網絡請求時觸發

Scripting事件

事件	描述
Animation Frame Fired	一個定義好的動畫幀發生並開始回調處理時觸發
Cancel Animation Frame	取消一個動畫幀時觸發
GC Event	垃圾回收時觸發
DOMContentLoaded	當頁面中的DOM內容加載並解析完畢時觸發
Evaluate Script	A script was evaluated.
Event	js事件
Function Call	只有當瀏覽器進入到js引擎中時觸發
Install Timer	建立計時器（調用setTimeout()和setInterval()）時觸發
Request Animation Frame	A requestAnimationFrame() call scheduled a new frame
Remove Timer	當清除一個計時器時觸發
Time	調用console.time()觸發
Time End	調用console.timeEnd()觸發
Timer Fired	定時器激活回調後觸發
XHR Ready State Change	當一個異步請求爲就緒狀態後觸發
XHR Load	當一個異步請求完成加載後觸發

Rendering事件

事件	描述
Invalidate layout	當DOM更改致使頁面佈局失效時觸發
Layout	頁面佈局計算執行時觸發
Recalculate style	Chrome從新計算元素樣式時觸發
Scroll	內嵌的視窗滾動時觸發

Painting事件

事件	描述
Composite Layers	Chrome的渲染引擎完成圖片層合併時觸發
Image Decode	一個圖片資源完成解碼後觸發
Image Resize	一個圖片被修改尺寸後觸發
Paint	合併後的層被繪製到對應顯示區域後觸發

參考文檔

https://developers.google.com/chrome-dev...

http://www.w3cfuns.com/article-1248-1.ht...

http://www.oschina.net/translate/perform...