https://gold.xitu.io/entry/5784d620a633bd00668113fc
網站的速度影響了用戶訪問網站最初的體驗。試想，如果一個用戶，在等待了若干秒后，還是停留在白屏的狀態，那么他的選擇將是離開這個網站。性能統計有助於幫我們檢測網站的用戶體驗。
這里引用百度百科中的一句話 ---- 通常一個網站，如果首屏時間在2秒以內是比較優秀的，5秒以內是可以接受的，5秒以上就不可容忍了。用戶會選擇刷新頁面或立刻離開。
這里，有些數據需要與大家分享一下(來自FEX的統計)：
| 產品 | 性能 | 收益 |
| 延遲 400ms | 搜索量下降 0.59% | |
| Bing | 延遲 2s | 收入下降 4.3% |
| Yahoo | 延遲 400ms | 流量下降 5-9% |
| Mozilla | 頁面打開減少 2.2s | 下載量提升 15.4% |
| Netflix | 開啟 Gzip性能提升 13.25% | 帶寬減少50% |
1、網站都有哪些指標？
1.1 首屏時間
這個指標對於大多數網站來說，非常重要。那么何為首屏時間呢？引用百度百科里的一句話，就是:
網站用戶體驗的一個重要指標。 指一個網站被瀏覽器如IE窗口上部800*600的區域被充滿所需時間。
其實就是你的網頁剛進入時，渲染完整個瀏覽器屏幕的時間。
關於是否包含首屏所有的圖片下載完成。這個網上有些爭議，有的同學說不包含圖片，只要DOM+樣式 都渲染完了，就算完成了。
筆者認為，既然是首屏，那么首屏上所有的東西都加載完成，讓用戶感受不到還有沒完成的部分，就算完成了。
所以，綜合一下，咱們的首屏時間，包括首屏的DOM元素的渲染，展現在用戶第一屏幕的所有圖片都完成。
其實Chrome提供開發着檢查網站整個渲染過程的小公舉，哦不，是小工具（如圖1.1.1所示）在F12開發者工具的Network面板里面：
圖1.1.1
這個是屏幕捕獲的工具，可以看到整個網頁的渲染過程。我們接着來深究一下上述哪個時間點是首屏時間點。
我們來一起看看百度首頁的首屏情況，由於百度首頁加載比較快，所以這里咱們模擬一下3G網的延遲（如圖1.1.2）：
圖1.1.2
我們看到，雖然在240ms的時候，網頁算是被渲染出來了，但是還是有很多空白的地方。
279MS的時候，雖然框架都被渲染完成了，DOM與樣式也都渲染完成了，但是我們看到圖片還不完整，所以，當然也不算首屏完成了。
有的同學會說，318ms的時候，總算完成了吧，nonono，我們向后觀察，就會發現還有一些元素會再被渲染出來。也就是說知道穩定之前，我們都不能算首屏完成了。
知道487 ms的時候，頁面才算加載完成了。並且之后不會再發生頁面的抖動了。
看完這些，相信聰明的你心里已經有數了，什么是首屏時間。
1.2 白屏時間
這個其實不多說，讀者也明白，就是頁面處於空白的時間。頁面空白，用戶就會焦躁，並且變得不耐心。影響白屏時間的多數是：DNS解析耗時+服務端耗時+網絡傳輸耗時。
1.3 用戶可操作時間
顧名思義，這項指標值得是，我們的網頁用戶可以使用的時間。一般來講 domready時間，便是我們的用戶可操作時間了。
1.4 總下載時間
通常指，頁面總體的下載時間，所有的頁面資源都下載完成。
1.5 自定義指標
由於業務不同，站長們所關心的時間必然也不同了。比如你可能是一個電商網站的站長，你關心你的第一屏商品到底展示的有多快( 通常這會帶來更多的收入)，所以，你需要監控你的商品展現的時間。
2 如何統計自己網站的這些指標
如果並不想要花費精力在這些統計上，只是要小小的關注一下的話，當然可以自己打開控制台，在頁面的各個階段，將時間打印出來，亦或者是使用html5新增的接口：performance來評估一下自己的網站到底差在哪里(如圖2.0.1)。
圖2.0.1
但是，你的測試並不能代表所有的用戶的情況。而且，你需要一個監控程序，去時刻提醒着你，現在你的網站的速度處於什么狀況。
所以，對於有追求一些的站長而言，筆者在這里更建議采用用戶日志，即，在自己網站的代碼中，增加統計，並把統計結果發送到服務器。在服務器采集這些日志，並產生一個監控的網站。其實大可不必使用一些付費的服務，我們自己就可以輕輕松松的做一個簡答的速度監控服務。
在本文的第三節，我們將會一起做一個小的速度監控服務的例子。很多站長甚至可以拿過來直接使用。接下來，我們還是針對之前我們提到過的幾個指標，注意講解統計方法：
2.1 如何統計首屏時間
其實，對於網頁高度小於屏幕的網站來說，統計首屏時間非常的簡單，只要在頁面底部加上腳本打印當前時間即可，或者對於網頁高度大於一屏的網頁來說，只要在估算接近於一屏幕的元素的位置后，打印一下當前時間即可。
比如，現在你有一個簡單的網頁（如圖2.1.1所示）：
圖2.1.1
我們需要統計首屏時間的話，則需要定義一個基准，就是--什么時候用戶點開的當前網頁，HTML5的performance接口提供了這個時間：performance.timing.navigationStart，這個就是用戶訪問我們網頁最開始的跳轉時間了。
我們在頁面開頭處，將基准記下。
接下來，在大約的首屏處加上我們的統計：
我們再來看看我們的頁面(如圖2.1.2所示)：
圖2.1.2
便有了首屏時間。
霸特，霸特。同學們不要激動的太早。我們這個首屏時間，並不沒有算上圖片。所以，我們得把首屏中所有圖片的加載時間也算上。
以上封裝的首屏時間函數，無依賴比較小巧，同學們可以直接使用於自己的項目中。這樣，我們就輕輕松松的統計到了首屏時間。
2.2 如何統計白屏時間
可以在頁面的head底部添加的JS代碼來統計白屏時間，雖然這樣做可能並不十分精准，但是也可以基本代表了首屏時間，如圖2.2.1所示。
圖2.2.1
2.3 如何統計用戶可操作時間
前面提到過document.ready其實就可以算作我們的用戶可操作時間啦。我們不妨直接試試，如圖2.3.1所示：
圖2.3.1
2.4 如何打印總下載時間
頁面總體下載時間，使用window.onload即可，這可以幫助我們看看我們所有的資源是否拖慢網頁，如圖2.4.1所示：
圖2.4.1
2.5 統一打印時間，更方便
我們將上述的統計合並，一個完整的統計就出來了，如圖2.5.1所示：
圖2.5.1
我們將這個日志發送到服務端去。
開啟我們的nginx監聽，並在服務端接收這條日志如圖2.5.2，圖2.5.3所示：
圖2.5.2
圖2.5.3
我們看看日志里面是不是已經多了一條了呢？
要是再加以定時任務，日志采集等功能的輔助，我們就能實時掌握自己網站的性能啦。