用 Chrome 來診斷前端頁面性能

Chrome提供了全部主流瀏覽器中最強大的診斷頁面性能的工具，咱們這裏就依照咱們團隊項目爲例子，來介紹下這個工具的使用：

Timeline Check:

首先，咱們去檢查了載入首頁的timeline,我測試了8次，平均下來，大概要花費我5.3秒的時間。

從這裏咱們能夠看到如下結論：

(1)全部的資源文件，好比js文件，或者css文件，都是並行的加載的， 因此從timeline圖上能夠看出來，它們是同時發生的。也就是上圖中全部小藍色的圓點都同時開始的，固然那個藍條有長短，由於各個資源文件有大小區別。

(2)Parsing 這個步驟花費了很是多的時間，它大概用了1.52秒：

當咱們深刻細節以後，咱們發現，它主要是用來解析/評測各個js文件，安裝定時器，激活瀏覽器的垃圾回收事件等。

(3)另一個消耗時間比較多的地方在於以下url:

test?p_p_id=envprovisioningportlet_WAR_envprovisioningportlet&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_resource_id=paginationRequestInfo&p_p_cacheability=cacheLevelPage&p_p_col_id=column1&p_p_col_count=1&_dc+1369363077815&start=0&limit=20&page=1

這是由於咱們須要填充第一個grid，並且咱們使用的是ajax,而ajax須要調用時間。

Profiler:

這個是專門用來分析頁面訪問低速度的工具。

首先，咱們來檢查CPU的執行時間：

咱們看下全部的js的函數的執行，能夠發現如下的函數佔據了太多的CPU時間：

一個是app.js的第8行->Ext.application.launch 方法

一個是AEREnvGrid.js第8行->Ext.define.initComponent方法：

接下來咱們來檢查CSS選擇器的選擇時間：

經驗告訴咱們，類選擇器，父子選擇器總會比id選擇器佔據更多的時間，咱們這裏按照時間排序能夠看出花費時間較多的都是這些選擇器：

按照這樣的思路，咱們能很快的分析咱們的代碼中的大多數影響前端性能的問題。