在這個信息爆炸的互聯網時代，愈來愈多的人缺乏了等待的耐心。站點性能對於一個站點來講愈來愈重要。下面爲監控到的站點打開時間對跳出率的影響：javascript
- 當站點打開時間在0-1秒時，跳出率爲12%
- 當站點打開時間在1-2秒時，跳出率爲26%
- 當站點打開時間在2-3秒時，跳出率爲30%
從上面的數據很是明顯的可以看到站點的打開速度對用戶體驗或者站點信任度的影響會產生多大的影響。html
1、怎樣監控站點的性能html5
一、工具類java
這部分主要介紹的是站點性能的檢測工具。工具類的監控主要長處是調試方便，缺點就是不能準確的或者用戶的真實訪問數據。詳細的工具備：ios
- Google Page Speed https://developers.google.com/speed/pagespeed/
- Google Speed Tracer https://developers.google.com/web-toolkit/speedtracer/?
hl=zh-CNweb
- Yahoo Yslow http://yslow.org/
- Fiddler http://fiddler2.com/ （軟件介紹）
- HttpWatch http://www.httpwatch.com/
- HTTP Analyzer http://www.ieinspector.com/
上面的工具備的免費，有點收費，但是總體的功能差點兒相同。當中Google Speed Tracer使用起來可能會比較麻煩些，有機會在具體介紹這個工具的用法。chrome
二、探測類編程
普通測試類的站點有：瀏覽器
- 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/）
三、監控類
四、server監控
- Nagios http://www.nagios.org/
- Cacti http://www.cacti.net/
2、監控系統的現狀
眼下第三方監控作的較好的主要爲基調網絡和監控寶，當中基調網絡監控的數據更加具體完整，屬於高富帥產品，而監控寶相對的更加平民化些，下面是針對這兩個服務的分析。
優點
- 無需修改現有程序代碼。第三方監控由於採用主動訪問並採集的機制，僅僅需要在用戶管理界面配置相關頁面的URL，就可以模擬用戶訪問的過程。於是全然不需要開發者介入。
- 能採集到豐富的數據。因爲模擬訪問使用的瀏覽器由供應商部署。因此可以在client增長本身定義插件或集成其它性能工具，能經過編程實現各種性能數據的採集。
劣勢
- 成本比較大，以基調爲例，若是要作到天天，每半小時監控一次的話，若是需要監控的終點頁面爲20個，全國要監控50個節點，每個節點3個線路，每個線路兩臺電腦的話，大概費用是天天1500元。而監控寶相對於基調網絡監控的數據比較單一。成本相對要低些。每一年要作到基本全面監控需要花4000元。
- 監控點有限，不能覆蓋整體用戶羣。監控點可以添加，但老是沒法覆蓋所有的網絡環境，比方用戶開着迅雷下下載內容等。所以數據僅僅能用於參考。並不能表明真有用戶感覺。
- 監控有時間間隔。都是按事先設定好的頻率進行監控，在間隔中間點如發生故障，沒法獲知。且頻率與費用成正比關係。頻率越高費用越高。
- 對於強依賴流程進入的頁面難以監控。好比預訂流程。需要POST大量信息，且有時效性，對於監測點來講具備必定的挑戰。
另外除了上述兩種方法，前面的文章中說到了可以用GA來統計站點打開時間。
詳細原理爲：
在頁面的頭部和底部分加入
- var _nStartTime = new Date().getTime();
- var _nEndTime = new Date().getTime();
二者的時間時間差即爲頁面的打開時間。但是此方法有很是多的弊端，不過統計了用戶的部分耗時，當中不包含，鏈接時間、DNS解析時間、首包時間等。
上述統計的時間，並不能真實的反應用戶的打開時間。
3、性能監控需要關注哪些指標
下面爲一些指標主要針對前臺頁面的載入。
- 頁面載入時間：從DNS解析開始到返回所有文件內容所用的時間
- DNS解析時間：站點域名經過 DNS server解析到IP地址的時間
- 初始化鏈接時間：瀏覽器和WEBserver創建TCP/IP鏈接的消耗時間
- 首字節時間：從發起頁面請求至server端返回第一個字節
- 下載時間：從接收server發回的第一字節至主頁面下載完畢
- 渲染時間：從頁面跳轉至頁面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 (用戶經過後退button訪問本頁面)
- 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 返回用戶代理向serverserver請求文檔開始創建鏈接的那個時間。假設此鏈接是一個長鏈接又或者直接從緩存中獲取資源（即沒有與server創建鏈接）則返回domainLookupEnd的值。
- .connectEnd 返回用戶代理向serverserver請求文檔創建鏈接成功後（注意。不是斷開鏈接的時間）的那個時間。假設此鏈接是一個長鏈接又或直接從緩存中獲取資源 （即沒有與server創建鏈接）,則返回domainLookupEnd的值。假設鏈接創建失敗而用戶代理進行重連則connectStart和connectEnd則應該是此次重連的相關的值。當中connectEnd必須包含創建鏈接的時間以及SSH握手協議和SOCKS認證等時間。
- .secureConnectionStart 可選特性。用戶代理假設沒有相應的東東就要把這個設置爲undefined，假設有這個東東並且是HTTPS協議那麼就要返回開始SSL握手的那個時間。
假設不是HTTPS那麼就返回0。
- .requestStart 返回從server、緩存、本地資源等開始請求文檔的時間。
假設請求中途鏈接斷開了並且用戶代理進行了重連並又一次請求了資源。那麼requestStart就必須爲這個新請求所相應的時間。
- .responseStart 返回用戶代理從server、緩存、本地資源中接收到第一個字節數據的時間。
- .responseEnd 返回用戶代理接收到最後一個字符的時間。和當前鏈接被關閉的時間中更早的那個。相同文檔可能來自server、緩存、或本地資源。
- .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()
上面的數據也可用來作性能的監測。
參考文章