摘要：性能統計有助于幫我們檢測網站的用戶體驗。這樣，我們就輕輕松松的統計到了首屏時間。下一章，我們將繼續聊聊百度移動版首頁那些事。

歡迎大家收看聊一聊系列，這一套系列文章，可以幫助前端工程師們了解前端的方方面面（不僅僅是代碼）：

https://segmentfault.com/blog/frontenddriver

上一篇文章我們討論了，如何進行前端日志打點統計：

https://segmentfault.com/a/1190000005861012

這一篇我們來看看如何進行速度統計

網站的速度影響了用戶訪問網站最初的體驗。試想，如果一個用戶，在等待了若干秒后，還是停留在白屏的狀態，那么他的選擇將是離開這個網站。性能統計有助于幫我們檢測網站的用戶體驗。

這里引用百度百科中的一句話 ----?通常一個網站，如果首屏時間在2秒以內是比較優秀的，5秒以內是可以接受的，5秒以上就不可容忍了。用戶會選擇刷新頁面或立刻離開。

這里，有些數據需要與大家分享一下(來自FEX的統計)：

可以看到，速度，對于一個網站來說，重要性可見一斑。

這個指標對于大多數網站來說，非常重要。那么何為首屏時間呢？引用百度百科里的一句話，就是:

網站用戶體驗的一個重要指標。　指一個網站被瀏覽器如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的時候，頁面才算加載完成了。并且之后不會再發生頁面的抖動了。

看完這些，相信聰明的你心里已經有數了，什么是首屏時間。

? ? 這個其實不多說，讀者也明白，就是頁面處于空白的時間。頁面空白，用戶就會焦躁，并且變得不耐心。影響白屏時間的多數是：DNS解析耗時+服務端耗時+網絡傳輸耗時。

? ? 顧名思義，這項指標值得是，我們的網頁用戶可以使用的時間。一般來講 domready時間，便是我們的用戶可操作時間了。

? ? 通常指，頁面總體的下載時間，所有的頁面資源都下載完成。

? ? 由于業務不同，站長們所關心的時間必然也不同了。比如你可能是一個電商網站的站長，你關心你的第一屏商品到底展示的有多快( 通常這會帶來更多的收入)，所以，你需要監控你的商品展現的時間。

如果并不想要花費精力在這些統計上，只是要小小的關注一下的話，當然可以自己打開控制臺，在頁面的各個階段，將時間打印出來，亦或者是使用html5新增的接口：performance來評估一下自己的網站到底差在哪里(如圖2.0.1)。

圖2.0.1

但是，你的測試并不能代表所有的用戶的情況。而且，你需要一個監控程序，去時刻提醒著你，現在你的網站的速度處于什么狀況。

????所以，對于有追求一些的站長而言，筆者在這里更建議采用用戶日志，即，在自己網站的代碼中，增加統計，并把統計結果發送到服務器。在服務器采集這些日志，并產生一個監控的網站。其實大可不必使用一些付費的服務，我們自己就可以輕輕松松的做一個簡答的速度監控服務。

? ? 在本文的第三節，我們將會一起做一個小的速度監控服務的例子。很多站長甚至可以拿過來直接使用。接下來，我們還是針對之前我們提到過的幾個指標，注意講解統計方法：

? ??其實，對于網頁高度小于屏幕的網站來說，統計首屏時間非常的簡單，只要在頁面底部加上腳本打印當前時間即可，或者對于網頁高度大于一屏的網頁來說，只要在估算接近于一屏幕的元素的位置后，打印一下當前時間即可。

? ? 比如，現在你有一個簡單的網頁（如圖2.1.1所示）：

    
        
        
    
    
        
這是第一屏，這是第一屏
        
        
        
        
        
第一屏結尾，第一屏結尾
        
        
    

圖2.1.1

我們需要統計首屏時間的話，則需要定義一個基準，就是--什么時候用戶點開的當前網頁，HTML5的performance接口提供了這個時間：performance.timing.navigationStart，這個就是用戶訪問我們網頁最開始的跳轉時間了。

我們在頁面開頭處，將基準記下。

接下來，在大約的首屏處加上我們的統計：

第一屏結尾，第一屏結尾

我們再來看看我們的頁面(如圖2.1.2所示)：

圖2.1.2

便有了首屏時間。

霸特，霸特。同學們不要激動的太早。我們這個首屏時間，并不沒有算上圖片。所以，我們得把首屏中所有圖片的加載時間也算上。

    
        
        
        
    
    
        
這是第一屏，這是第一屏
        
        
        
        
        
第一屏結尾，第一屏結尾
        
        
        
    

以上封裝的首屏時間函數，無依賴比較小巧，同學們可以直接使用于自己的項目中。這樣，我們就輕輕松松的統計到了首屏時間。

????可以在頁面的head底部添加的JS代碼來統計白屏時間，雖然這樣做可能并不十分精準，但是也可以基本代表了首屏時間，如圖2.2.1所示。

圖2.2.1

????前面提到過document.ready其實就可以算作我們的用戶可操作時間啦。我們不妨直接試試，如圖2.3.1所示：

document
.addEventListener(
    "DOMContentLoaded",
    function (event) {
        window.logInfo.readyTime = +new Date() - window.logInfo.openTime;
        console.log("用戶可操作時間：", window.logInfo.readyTime);
    }
);

圖2.3.1

????頁面總體下載時間，使用window.onload即可，這可以幫助我們看看我們所有的資源是否拖慢網頁，如圖2.4.1所示：

window.onload = function () {
    window.logInfo.allloadTime = +new Date() - window.logInfo.openTime;
    console.log("總下載時間：", window.logInfo.allloadTime + "ms");
};

圖2.4.1

? ? 我們將上述的統計合并，一個完整的統計就出來了，如圖2.5.1所示：

    
        
        
        
    
    
        
這是第一屏，這是第一屏
        
        
        
        
        
第一屏結尾，第一屏結尾
        
        
        
    

圖2.5.1

按照上一節( https://segmentfault.com/a/1190000005861012 )所說，我們將這個日志發送到服務端去。

var logStr = "";
for (var i in timname) {
    logStr += "&" + i + "=" + window.logInfo[i];
}
(new Image()).src = "http://localhost:8091/?action=speedlog" + logStr;

開啟我們的nginx監聽，并在服務端接收這條日志如圖2.5.2，圖2.5.3所示：

圖2.5.2

圖2.5.3

我們看看日志里面是不是已經多了一條了呢？

要是再加以定時任務，日志采集等功能的輔助，我們就能實時掌握自己網站的性能啦。

https://segmentfault.com/a/1190000005882953

后續，我們也會一起來聊聊，如何優化我們的這些速度，以提高我們的網站性能。

原創文章,版權所有,轉載請注明出處