使用HTML5監測網站性能

在這個信息爆炸的互聯網時代，愈來愈多的人缺乏了等待的耐心，網站性能對於一個網站來講愈來愈重要。如下爲監控到的網站打開時間對跳出率的影響：

• 當網站打開時間在0-1秒時，跳出率爲12%
• 當網站打開時間在1-2秒時，跳出率爲26%
• 當網站打開時間在2-3秒時，跳出率爲30%

從上面的數據很明顯的能夠看到網站的打開速度對用戶體驗或者網站信任度的影響會產生多大的影響。

1、如何監控網站的性能

一、工具類

這部分主要介紹的是網站性能的檢測工具，工具類的監控主要優勢是調試方便，缺點就是不能準確的或者用戶的真實訪問數據。具體的工具備：

• Google Page Speed  https://developers.google.com/speed/pagespeed/
• Google Speed Tracer  https://developers.google.com/web-toolkit/speedtracer/?hl=zh-CN
• Yahoo Yslow http://yslow.org/
• Fiddler http://fiddler2.com/ （軟件介紹）
• HttpWatch http://www.httpwatch.com/
• HTTP  Analyzer http://www.ieinspector.com/

上面的工具備的免費，有點收費，可是整體的功能差很少。其中Google Speed Tracer使用起來可能會比較麻煩些，有機會在詳細介紹這個工具的使用方法。

二、探測類

普通測試類的網站有：

• 360網速測試 http://webscan.360.cn/tools/http
• 17測 http://www.17ce.com/
• 卡卡網 http://www.webkaka.com/
• Webluker http://www.webluker.com/webtools/net

詳細測試類的網站有：

阿里測 http://www.alibench.com/ （來自於阿里巴巴，抄襲對象爲 http://www.webpagetest.org/）

三、監控類

• 監控寶 http://www.jiankongbao.com/
• 基調網絡 http://www.networkbench.com/

四、服務器監控

• Nagios http://www.nagios.org/
• Cacti http://www.cacti.net/

2、監控系統的現狀

目前第三方監控作的較好的主要爲基調網絡和監控寶，其中基調網絡監控的數據更加詳細完整，屬於高富帥產品，而監控寶相對的更加平民化些，如下是針對這兩個服務的分析。

優點

1. 無需改動現有程序代碼。第三方監控因爲採用主動訪問並採集的機制，只須要在用戶管理界面配置相關頁面的URL，就能夠模擬用戶訪問的過程，於是徹底不須要開發人員介入。
2. 能採集到豐富的數據。由於模擬訪問使用的瀏覽器由供應商部署，因此能夠在客戶端加入自定義插件或集成其餘性能工具，能經過編程實現各種性能數據的採集。

劣勢

1. 成本比較大，以基調爲例，若是要作到天天，每半小時監控一次的話，假設須要監控的終點頁面爲20個，全國要監控50個節點，每一個節點3個線路，每一個線路兩臺電腦的話，大概費用是天天1500元。而監控寶相對於基調網絡監控的數據比較單一，成本相對要低些，每一年要作到基本全面監控須要花4000元。
2. 監控點有限，不能覆蓋總體用戶羣。監控點能夠增長，但老是沒法覆蓋全部的網絡環境，好比用戶開着迅雷下下載內容等，所以數據只能用於參考，並不能表明真實用戶感覺。
3. 監控有時間間隔，都是按事先設定好的頻率進行監控，在間隔中間點如發生問題，沒法獲知，且頻率與費用成正比關係，頻率越高費用越高。
4.  對於強依賴流程進入的頁面難以監控。例如預訂流程，須要POST大量信息，且有時效性，對於監測點來講具備必定的挑戰。

另外除了上述兩種方法，前面的文章中說到了能夠用GA來統計網站打開時間。具體原理爲：

在頁面的頭部和底部分添加

• var _nStartTime = new Date().getTime();
• var _nEndTime = new Date().getTime();

二者的時間時間差即爲頁面的打開時間。可是此方法有不少的弊端，僅僅是統計了用戶的部分耗時，其中不包括，鏈接時間、DNS解析時間、首包時間等。上述統計的時間，並不能真實的反應用戶的打開時間。

3、性能監控須要關注哪些指標

如下爲一些指標主要針對前臺頁面的加載。

• 頁面加載時間：從DNS解析開始到返回全部文件內容所用的時間
• DNS解析時間：網站域名經過 DNS 服務器解析到IP地址的時間
• 初始化鏈接時間：瀏覽器和WEB服務器創建TCP/IP鏈接的消耗時間
• 首字節時間：從發起頁面請求至服務器端返回第一個字節
• 下載時間：從接收服務器發回的第一字節至主頁面下載完成
• 渲染時間：從頁面跳轉至頁面Dom元素穩定。

4、HTML5提供了哪些信息

HTML5草案中提供了 window.preformance的API，可經過此API進行網站新能的監測。全部數據可以使用javascript獲取window.performance.timing中的以下屬性獲取：

其中每一個屬性的具體含義爲：

對象：window.performance.

成員:

• .navigation (一個叫作performanceNavigation的對象.)
• .timing (這玩意是一個被稱做performanceTiming的包含了不少成員的對象)

方法:

• .toJSON （返回一個對象，並抄寫performance的可枚舉成員到其中）

performanceNavigation(performance.navigation)對象的成員

performanceNavigation.type

返回值應該是0,1,2 中的一個.分別對應三個枚舉值:

• 0 : TYPE_NAVIGATE  (用戶經過常規導航方式訪問頁面，好比點一個連接或者通常的get方式)
• 1 : TYPE_RELOAD  (用戶經過刷新，包括JS調用刷新接口等方式訪問頁面)
• 2 : TYPE_BACK_FORWARD (用戶經過後退按鈕訪問本頁面)
• 3 : TYPE_RESERVED (保留，其餘非前三種方式訪問)

performanceNavigation.redirectCount

一個只讀屬性，返回當前頁面是幾回重定向纔過來的。可是這個接口有同源策略限制，即僅能檢測同源的重定向。

performanceTiming(performance.timing)對象的成員:

• .navigationStart 瀏覽器完成卸載前一個文檔的時間（也就是準備加載新頁面的那個起始時間）。若是沒有前一個文檔，那麼就返回timing.fetchStart的值。彷佛只有Chrome很是嚴格遵照了此草案，即不把刷新頁面以及一個標籤頁輸入地址到指定頁面視爲發生文檔的卸載。
• .unloadEventStart 若是前一個文檔和當前文檔同源，返回前一個文檔發生unload事件前的時間。若是沒有前一個文檔或不一樣源則返回0。
• .unloadEventEnd 若是前一個文檔和當前文檔同源，返回前一個文檔發生unload事件的時間。若是沒有前一個文檔或不一樣源則返回0。若是，發生了HTTP重定向或者相似的事情。而且從導航開始中間的每次重定向，並不都和當前文檔同域的話則返回0。
• .redirectStart 若是發生了HTTP重定向或者相似的事情，而且從導航開始中間的每次重定向都和當前文檔同域的話就返回開始重定向的timing.fetchStart的值。其餘狀況則返回0。
• .redirectEnd 若是發生了HTTP重定向或者相似的事情，而且從導航開始中間的每次重定向都和當前文檔同域的話就返回最後一次重定向，接收到最後一個字節數據後的那個時間。其餘狀況則返回0。
• .fetchStart 若是一個新的資源（這裏是指當前文檔）獲取被髮起或相似的事情發生則fetchStart必須返回用戶代理開始檢查其相關緩存的那個時間，其餘狀況則返回開始獲取該資源的時間。
• .domainLookupStart 返回用戶代理對當前文檔所屬域進行DNS查詢開始的時間。若是此請求沒有DNS查詢過程，如長鏈接、資源cache、甚至是本地資源等那麼就返回fetchStart的值。
• .domainLookupEnd 返回用戶代理對結束對當前文檔所屬域進行DNS查詢的時間。若是此請求沒有DNS查詢過程，如長鏈接、資源cache、甚至是本地資源等. 那麼就返回fetchStart的值。
• .connectStart 返回用戶代理向服務器服務器請求文檔開始創建鏈接的那個時間，若是此鏈接是一個長鏈接又或者直接從緩存中獲取資源（即沒有與服務器創建鏈接）則返回domainLookupEnd的值。
• .connectEnd 返回用戶代理向服務器服務器請求文檔創建鏈接成功後（注意，不是斷開鏈接的時間）的那個時間。若是此鏈接是一個長鏈接又或直接從緩存中獲取資源 （即沒有與服務器創建鏈接）,則返回domainLookupEnd的值。若是鏈接創建失敗而用戶代理進行重連則connectStart和connectEnd則應該是此次重連的相關的值。其中connectEnd必須包括創建鏈接的時間以及SSH握手協議和SOCKS認證等時間。
• .secureConnectionStart 可選特性。用戶代理若是沒有對應的東東就要把這個設置爲undefined，若是有這個東東而且是HTTPS協議那麼就要返回開始SSL握手的那個時間。若是不是HTTPS那麼就返回0。
• .requestStart 返回從服務器、緩存、本地資源等開始請求文檔的時間。若是請求中途鏈接斷開了而且用戶代理進行了重連並從新請求了資源，那麼requestStart就必須爲這個新請求所對應的時間。
• .responseStart 返回用戶代理從服務器、緩存、本地資源中接收到第一個字節數據的時間。
• .responseEnd 返回用戶代理接收到最後一個字符的時間，和當前鏈接被關閉的時間中更早的那個。一樣文檔可能來自服務器、緩存、或本地資源。
• .domLoading 返回用戶代理把其文檔的「current document readiness」設置爲「loading」的時候。（current document readiness 其實就是document.readyState API對應的狀態。）
• .domInteractive 返回用戶代理把其文檔的「current document readiness」設置爲「interactive」的時候。從標準來講domReady的狀態爲「interactive」時意味着文檔解析結束了，由於標準中描述DOM樹建立結束後第一件事就是把「current document readiness」設置爲「interactive」。
• .domContentLoadedEventStart 返回文檔發生DOMContentLoaded事件的時間。DOMContentLoad和DOMInteractive之間差了兩個步驟，其中之一是全部open elements出棧，而後去看看待運行的script list中是否有須要運行的腳本，若是有則執行，一直到這個列表爲空了再觸發DOMContentLoad.。須要主的是這個待運行腳本列表。有些可能在不一樣瀏覽器中被加入進去的行爲可能不一樣。好比 document.write寫入文檔流的腳本，以及script deferr 的腳本.. 因此咱們應該知道deferr的腳本也是要他推遲domContentLoaded的，也就是咱們最經常使用的所謂domReady。
• .domContentLoadedEventEnd 文檔的DOMContentLoaded事件的結束時間。所謂事件結束的時間是指若是DOMContentLoaded事件被開發者註冊了回調事件，那麼這個時間的End時間減去Start的時間就會是這個回調執行的大概事件。固然居於部分瀏覽器實現可能會有2-3ms的偏差，可是這個時間基本能夠忽略不計。相似的狀況還有後面的.loadEventStart,End，即 window.onload 全部回調所消耗的時間。
• .domComplete 返回用戶代理把其文檔的「current document readiness」設置爲「complete」的時候。若是current document readiness的某個狀態被屢次觸發那麼對應的domLoading, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd and domComplete這些對應的API返回的時間就應該是這個狀態第一次觸發的時間。
• .loadEventStart 文檔觸發load事件的時間。若是load事件沒有觸發那麼該接口就返回0。
• .loadEventEnd 文檔觸發load事件結束後的時間。若是load事件沒有觸發,那麼該接口就返回0。

因爲使用的是HTML5技術，因此目前支持的瀏覽器有限，具體詳情可查看這裏。

另外除了HTML5提供的接口之外，Chrome還提供了另一套是有的方法：chrome.loadTimes()

上面的數據也可用來作性能的監測。