摘要:性能統(tǒng)計有助于幫我們檢測網(wǎng)站的用戶體驗。這樣,我們就輕輕松松的統(tǒng)計到了首屏?xí)r間。下一章,我們將繼續(xù)聊聊百度移動版首頁那些事。
歡迎大家收看聊一聊系列,這一套系列文章,可以幫助前端工程師們了解前端的方方面面(不僅僅是代碼):
https://segmentfault.com/blog/frontenddriver
上一篇文章我們討論了,如何進行前端日志打點統(tǒng)計:
https://segmentfault.com/a/1190000005861012
這一篇我們來看看如何進行速度統(tǒng)計
網(wǎng)站的速度影響了用戶訪問網(wǎng)站最初的體驗。試想,如果一個用戶,在等待了若干秒后,還是停留在白屏的狀態(tài),那么他的選擇將是離開這個網(wǎng)站。性能統(tǒng)計有助于幫我們檢測網(wǎng)站的用戶體驗。
這里引用百度百科中的一句話 ----?通常一個網(wǎng)站,如果首屏?xí)r間在2秒以內(nèi)是比較優(yōu)秀的,5秒以內(nèi)是可以接受的,5秒以上就不可容忍了。用戶會選擇刷新頁面或立刻離開。
這里,有些數(shù)據(jù)需要與大家分享一下(來自FEX的統(tǒng)計):
產(chǎn)品 | 性能 | 收益 |
---|---|---|
延遲?400ms | 搜索量下降?0.59% | |
Bing | 延遲?2s | 收入下降?4.3% |
Yahoo | 延遲?400ms | 流量下降?5-9% |
Mozilla | 頁面打開減少?2.2s | 下載量提升?15.4% |
Netflix | 開啟 Gzip性能提升 13.25% | 帶寬減少50% |
可以看到,速度,對于一個網(wǎng)站來說,重要性可見一斑。
1、網(wǎng)站都有哪些指標(biāo)? 1.1 首屏?xí)r間這個指標(biāo)對于大多數(shù)網(wǎng)站來說,非常重要。那么何為首屏?xí)r間呢?引用百度百科里的一句話,就是:
網(wǎng)站用戶體驗的一個重要指標(biāo)。 指一個網(wǎng)站被瀏覽器如IE窗口上部800*600的區(qū)域被充滿所需時間。
其實就是你的網(wǎng)頁剛進入時,渲染完整個瀏覽器屏幕的時間。
關(guān)于是否包含首屏所有的圖片下載完成。這個網(wǎng)上有些爭議,有的同學(xué)說不包含圖片,只要DOM+樣式 都渲染完了,就算完成了。
筆者認為,既然是首屏,那么首屏上所有的東西都加載完成,讓用戶感受不到還有沒完成的部分,就算完成了。
所以,綜合一下,咱們的首屏?xí)r間,包括首屏的DOM元素的渲染,展現(xiàn)在用戶第一屏幕的所有圖片都完成。
其實Chrome提供開發(fā)著檢查網(wǎng)站整個渲染過程的小公舉,哦不,是小工具(如圖1.1.1所示)在F12開發(fā)者工具的Network面板里面:
圖1.1.1
這個是屏幕捕獲的工具,可以看到整個網(wǎng)頁的渲染過程。我們接著來深究一下上述哪個時間點是首屏?xí)r間點。
我們來一起看看百度首頁的首屏情況,由于百度首頁加載比較快,所以這里咱們模擬一下3G網(wǎng)的延遲(如圖1.1.2):
圖1.1.2
我們看到,雖然在240ms的時候,網(wǎng)頁算是被渲染出來了,但是還是有很多空白的地方。
279MS的時候,雖然框架都被渲染完成了,DOM與樣式也都渲染完成了,但是我們看到圖片還不完整,所以,當(dāng)然也不算首屏完成了。
有的同學(xué)會說,318ms的時候,總算完成了吧,nonono,我們向后觀察,就會發(fā)現(xiàn)還有一些元素會再被渲染出來。也就是說知道穩(wěn)定之前,我們都不能算首屏完成了。
知道487 ms的時候,頁面才算加載完成了。并且之后不會再發(fā)生頁面的抖動了。
看完這些,相信聰明的你心里已經(jīng)有數(shù)了,什么是首屏?xí)r間。
1.2 白屏?xí)r間? ? 這個其實不多說,讀者也明白,就是頁面處于空白的時間。頁面空白,用戶就會焦躁,并且變得不耐心。影響白屏?xí)r間的多數(shù)是:DNS解析耗時+服務(wù)端耗時+網(wǎng)絡(luò)傳輸耗時。
1.3?用戶可操作時間? ? 顧名思義,這項指標(biāo)值得是,我們的網(wǎng)頁用戶可以使用的時間。一般來講 domready時間,便是我們的用戶可操作時間了。
1.4 總下載時間? ? 通常指,頁面總體的下載時間,所有的頁面資源都下載完成。
1.5 自定義指標(biāo)? ? 由于業(yè)務(wù)不同,站長們所關(guān)心的時間必然也不同了。比如你可能是一個電商網(wǎng)站的站長,你關(guān)心你的第一屏商品到底展示的有多快( 通常這會帶來更多的收入),所以,你需要監(jiān)控你的商品展現(xiàn)的時間。
2 如何統(tǒng)計自己網(wǎng)站的這些指標(biāo)如果并不想要花費精力在這些統(tǒng)計上,只是要小小的關(guān)注一下的話,當(dāng)然可以自己打開控制臺,在頁面的各個階段,將時間打印出來,亦或者是使用html5新增的接口:performance來評估一下自己的網(wǎng)站到底差在哪里(如圖2.0.1)。
圖2.0.1
但是,你的測試并不能代表所有的用戶的情況。而且,你需要一個監(jiān)控程序,去時刻提醒著你,現(xiàn)在你的網(wǎng)站的速度處于什么狀況。
????所以,對于有追求一些的站長而言,筆者在這里更建議采用用戶日志,即,在自己網(wǎng)站的代碼中,增加統(tǒng)計,并把統(tǒng)計結(jié)果發(fā)送到服務(wù)器。在服務(wù)器采集這些日志,并產(chǎn)生一個監(jiān)控的網(wǎng)站。其實大可不必使用一些付費的服務(wù),我們自己就可以輕輕松松的做一個簡答的速度監(jiān)控服務(wù)。
? ? 在本文的第三節(jié),我們將會一起做一個小的速度監(jiān)控服務(wù)的例子。很多站長甚至可以拿過來直接使用。接下來,我們還是針對之前我們提到過的幾個指標(biāo),注意講解統(tǒng)計方法:
2.1 如何統(tǒng)計首屏?xí)r間? ??其實,對于網(wǎng)頁高度小于屏幕的網(wǎng)站來說,統(tǒng)計首屏?xí)r間非常的簡單,只要在頁面底部加上腳本打印當(dāng)前時間即可,或者對于網(wǎng)頁高度大于一屏的網(wǎng)頁來說,只要在估算接近于一屏幕的元素的位置后,打印一下當(dāng)前時間即可。
? ? 比如,現(xiàn)在你有一個簡單的網(wǎng)頁(如圖2.1.1所示):
這是第一屏,這是第一屏第一屏結(jié)尾,第一屏結(jié)尾
圖2.1.1
我們需要統(tǒng)計首屏?xí)r間的話,則需要定義一個基準(zhǔn),就是--什么時候用戶點開的當(dāng)前網(wǎng)頁,HTML5的performance接口提供了這個時間:performance.timing.navigationStart,這個就是用戶訪問我們網(wǎng)頁最開始的跳轉(zhuǎn)時間了。
我們在頁面開頭處,將基準(zhǔn)記下。
接下來,在大約的首屏處加上我們的統(tǒng)計:
第一屏結(jié)尾,第一屏結(jié)尾
我們再來看看我們的頁面(如圖2.1.2所示):
圖2.1.2
便有了首屏?xí)r間。
霸特,霸特。同學(xué)們不要激動的太早。我們這個首屏?xí)r間,并不沒有算上圖片。所以,我們得把首屏中所有圖片的加載時間也算上。
這是第一屏,這是第一屏第一屏結(jié)尾,第一屏結(jié)尾
以上封裝的首屏?xí)r間函數(shù),無依賴比較小巧,同學(xué)們可以直接使用于自己的項目中。這樣,我們就輕輕松松的統(tǒng)計到了首屏?xí)r間。
2.2 如何統(tǒng)計白屏?xí)r間????可以在頁面的head底部添加的JS代碼來統(tǒng)計白屏?xí)r間,雖然這樣做可能并不十分精準(zhǔn),但是也可以基本代表了首屏?xí)r間,如圖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即可,這可以幫助我們看看我們所有的資源是否拖慢網(wǎng)頁,如圖2.4.1所示:
window.onload = function () { window.logInfo.allloadTime = +new Date() - window.logInfo.openTime; console.log("總下載時間:", window.logInfo.allloadTime + "ms"); };
圖2.4.1
? ? 我們將上述的統(tǒng)計合并,一個完整的統(tǒng)計就出來了,如圖2.5.1所示:
這是第一屏,這是第一屏第一屏結(jié)尾,第一屏結(jié)尾
圖2.5.1
按照上一節(jié)( https://segmentfault.com/a/1190000005861012 )所說,我們將這個日志發(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)多了一條了呢?
要是再加以定時任務(wù),日志采集等功能的輔助,我們就能實時掌握自己網(wǎng)站的性能啦。
不要走開,請關(guān)注我。下一章,我們將繼續(xù)聊聊百度移動版首頁那些事。https://segmentfault.com/a/1190000005882953
后續(xù),我們也會一起來聊聊,如何優(yōu)化我們的這些速度,以提高我們的網(wǎng)站性能。
原創(chuàng)文章,版權(quán)所有,轉(zhuǎn)載請注明出處
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/79881.html
摘要:性能統(tǒng)計有助于幫我們檢測網(wǎng)站的用戶體驗。這樣,我們就輕輕松松的統(tǒng)計到了首屏?xí)r間。下一章,我們將繼續(xù)聊聊百度移動版首頁那些事。 歡迎大家收看聊一聊系列,這一套系列文章,可以幫助前端工程師們了解前端的方方面面(不僅僅是代碼): https://segmentfault.com/blog/frontenddriver 上一篇文章我們討論了,如何進行前端日志打點統(tǒng)計: https://segm...
摘要:歡迎大家收看聊一聊系列,這一套系列文章,可以幫助前端工程師們了解前端的方方面面不僅僅是代碼什么是功能統(tǒng)計作為一名開發(fā),我們的產(chǎn)品發(fā)布出去之后,無論是產(chǎn)品還是運營,其實都是想及時了解產(chǎn)品對用戶產(chǎn)生的影響的。下一章,我們將繼續(xù)聊聊速度統(tǒng)計。 歡迎大家收看聊一聊系列,這一套系列文章,可以幫助前端工程師們了解前端的方方面面(不僅僅是代碼):https://segmentfault.com/bl...
摘要:歡迎大家收看聊一聊系列,這一套系列文章,可以幫助前端工程師們了解前端的方方面面不僅僅是代碼什么是功能統(tǒng)計作為一名開發(fā),我們的產(chǎn)品發(fā)布出去之后,無論是產(chǎn)品還是運營,其實都是想及時了解產(chǎn)品對用戶產(chǎn)生的影響的。下一章,我們將繼續(xù)聊聊速度統(tǒng)計。 歡迎大家收看聊一聊系列,這一套系列文章,可以幫助前端工程師們了解前端的方方面面(不僅僅是代碼):https://segmentfault.com/bl...
閱讀 2848·2023-04-26 01:02
閱讀 1874·2021-11-17 09:38
閱讀 798·2021-09-22 15:54
閱讀 2904·2021-09-22 15:29
閱讀 892·2021-09-22 10:02
閱讀 3444·2019-08-30 15:54
閱讀 2010·2019-08-30 15:44
閱讀 1601·2019-08-26 13:46