摘要：性能統(tǒng)計(jì)有助于幫我們檢測網(wǎng)站的用戶體驗(yàn)。這樣，我們就輕輕松松的統(tǒng)計(jì)到了首屏?xí)r間。下一章，我們將繼續(xù)聊聊百度移動版首頁那些事。

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

https://segmentfault.com/blog/frontenddriver

上一篇文章我們討論了，如何進(jìn)行前端日志打點(diǎn)統(tǒng)計(jì)：

https://segmentfault.com/a/1190000005861012

這一篇我們來看看如何進(jìn)行速度統(tǒng)計(jì)

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

這里引用百度百科中的一句話 ----?通常一個(gè)網(wǎng)站，如果首屏?xí)r間在2秒以內(nèi)是比較優(yōu)秀的，5秒以內(nèi)是可以接受的，5秒以上就不可容忍了。用戶會選擇刷新頁面或立刻離開。

這里，有些數(shù)據(jù)需要與大家分享一下(來自FEX的統(tǒng)計(jì))：

可以看到，速度，對于一個(gè)網(wǎng)站來說，重要性可見一斑。

這個(gè)指標(biāo)對于大多數(shù)網(wǎng)站來說，非常重要。那么何為首屏?xí)r間呢？引用百度百科里的一句話，就是:

網(wǎng)站用戶體驗(yàn)的一個(gè)重要指標(biāo)。　指一個(gè)網(wǎng)站被瀏覽器如IE窗口上部800*600的區(qū)域被充滿所需時(shí)間。

其實(shí)就是你的網(wǎng)頁剛進(jìn)入時(shí)，渲染完整個(gè)瀏覽器屏幕的時(shí)間。

關(guān)于是否包含首屏所有的圖片下載完成。這個(gè)網(wǎng)上有些爭議，有的同學(xué)說不包含圖片，只要DOM+樣式 都渲染完了，就算完成了。

筆者認(rèn)為，既然是首屏，那么首屏上所有的東西都加載完成，讓用戶感受不到還有沒完成的部分，就算完成了。

所以，綜合一下，咱們的首屏?xí)r間，包括首屏的DOM元素的渲染，展現(xiàn)在用戶第一屏幕的所有圖片都完成。

其實(shí)Chrome提供開發(fā)著檢查網(wǎng)站整個(gè)渲染過程的小公舉，哦不，是小工具（如圖1.1.1所示）在F12開發(fā)者工具的Network面板里面：

圖1.1.1

這個(gè)是屏幕捕獲的工具，可以看到整個(gè)網(wǎng)頁的渲染過程。我們接著來深究一下上述哪個(gè)時(shí)間點(diǎn)是首屏?xí)r間點(diǎn)。

我們來一起看看百度首頁的首屏情況，由于百度首頁加載比較快，所以這里咱們模擬一下3G網(wǎng)的延遲（如圖1.1.2）：

圖1.1.2

我們看到，雖然在240ms的時(shí)候，網(wǎng)頁算是被渲染出來了，但是還是有很多空白的地方。

279MS的時(shí)候，雖然框架都被渲染完成了，DOM與樣式也都渲染完成了，但是我們看到圖片還不完整，所以，當(dāng)然也不算首屏完成了。

有的同學(xué)會說，318ms的時(shí)候，總算完成了吧，nonono，我們向后觀察，就會發(fā)現(xiàn)還有一些元素會再被渲染出來。也就是說知道穩(wěn)定之前，我們都不能算首屏完成了。

知道487 ms的時(shí)候，頁面才算加載完成了。并且之后不會再發(fā)生頁面的抖動了。

看完這些，相信聰明的你心里已經(jīng)有數(shù)了，什么是首屏?xí)r間。

? ? 這個(gè)其實(shí)不多說，讀者也明白，就是頁面處于空白的時(shí)間。頁面空白，用戶就會焦躁，并且變得不耐心。影響白屏?xí)r間的多數(shù)是：DNS解析耗時(shí)+服務(wù)端耗時(shí)+網(wǎng)絡(luò)傳輸耗時(shí)。

? ? 顧名思義，這項(xiàng)指標(biāo)值得是，我們的網(wǎng)頁用戶可以使用的時(shí)間。一般來講 domready時(shí)間，便是我們的用戶可操作時(shí)間了。

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

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

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

圖2.0.1

但是，你的測試并不能代表所有的用戶的情況。而且，你需要一個(gè)監(jiān)控程序，去時(shí)刻提醒著你，現(xiàn)在你的網(wǎng)站的速度處于什么狀況。

????所以，對于有追求一些的站長而言，筆者在這里更建議采用用戶日志，即，在自己網(wǎng)站的代碼中，增加統(tǒng)計(jì)，并把統(tǒng)計(jì)結(jié)果發(fā)送到服務(wù)器。在服務(wù)器采集這些日志，并產(chǎn)生一個(gè)監(jiān)控的網(wǎng)站。其實(shí)大可不必使用一些付費(fèi)的服務(wù)，我們自己就可以輕輕松松的做一個(gè)簡答的速度監(jiān)控服務(wù)。

? ? 在本文的第三節(jié)，我們將會一起做一個(gè)小的速度監(jiān)控服務(wù)的例子。很多站長甚至可以拿過來直接使用。接下來，我們還是針對之前我們提到過的幾個(gè)指標(biāo)，注意講解統(tǒng)計(jì)方法：

? ??其實(shí)，對于網(wǎng)頁高度小于屏幕的網(wǎng)站來說，統(tǒng)計(jì)首屏?xí)r間非常的簡單，只要在頁面底部加上腳本打印當(dāng)前時(shí)間即可，或者對于網(wǎng)頁高度大于一屏的網(wǎng)頁來說，只要在估算接近于一屏幕的元素的位置后，打印一下當(dāng)前時(shí)間即可。

? ? 比如，現(xiàn)在你有一個(gè)簡單的網(wǎng)頁（如圖2.1.1所示）：

    
        
        
    
    
        
這是第一屏，這是第一屏
        
        
        
        
        
第一屏結(jié)尾，第一屏結(jié)尾
        
        
    

圖2.1.1

我們需要統(tǒng)計(jì)首屏?xí)r間的話，則需要定義一個(gè)基準(zhǔn)，就是--什么時(shí)候用戶點(diǎn)開的當(dāng)前網(wǎng)頁，HTML5的performance接口提供了這個(gè)時(shí)間：performance.timing.navigationStart，這個(gè)就是用戶訪問我們網(wǎng)頁最開始的跳轉(zhuǎn)時(shí)間了。

我們在頁面開頭處，將基準(zhǔn)記下。

接下來，在大約的首屏處加上我們的統(tǒng)計(jì)：

第一屏結(jié)尾，第一屏結(jié)尾

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

圖2.1.2

便有了首屏?xí)r間。

霸特，霸特。同學(xué)們不要激動的太早。我們這個(gè)首屏?xí)r間，并不沒有算上圖片。所以，我們得把首屏中所有圖片的加載時(shí)間也算上。

    
        
        
        
    
    
        
這是第一屏，這是第一屏
        
        
        
        
        
第一屏結(jié)尾，第一屏結(jié)尾
        
        
        
    

以上封裝的首屏?xí)r間函數(shù)，無依賴比較小巧，同學(xué)們可以直接使用于自己的項(xiàng)目中。這樣，我們就輕輕松松的統(tǒng)計(jì)到了首屏?xí)r間。

????可以在頁面的head底部添加的JS代碼來統(tǒng)計(jì)白屏?xí)r間，雖然這樣做可能并不十分精準(zhǔn)，但是也可以基本代表了首屏?xí)r間，如圖2.2.1所示。

圖2.2.1

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

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

圖2.3.1

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

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

圖2.4.1

? ? 我們將上述的統(tǒng)計(jì)合并，一個(gè)完整的統(tǒng)計(jì)就出來了，如圖2.5.1所示：

    
        
        
        
    
    
        
這是第一屏，這是第一屏
        
        
        
        
        
第一屏結(jié)尾，第一屏結(jié)尾
        
        
        
    

圖2.5.1

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

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

開啟我們的nginx監(jiān)聽，并在服務(wù)端接收這條日志如圖2.5.2，圖2.5.3所示：

圖2.5.2

圖2.5.3

我們看看日志里面是不是已經(jīng)多了一條了呢？

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

https://segmentfault.com/a/1190000005882953

后續(xù)，我們也會一起來聊聊，如何優(yōu)化我們的這些速度，以提高我們的網(wǎng)站性能。

原創(chuàng)文章,版權(quán)所有,轉(zhuǎn)載請注明出處