做者:劉遠洋前端
公司:微店 - 前端團隊git
日期:2018-03-05github
本文發表在 微店前端團隊 blognpm
在前端性能數據的獲取方法上,如今業內大多使用手動埋點的方式,即在代碼中,人工判斷首屏完成的位置,並在該處添加首屏記錄的代碼,相似:firstscreen.report()
這樣。數組
這樣作的簡單省事,但缺點也很明顯:dom
通用的監控需求混入了業務代碼中前端性能
須要頁面開發者自覺手動添加埋點代碼,在業務中埋點覆蓋率不必定能達到 100%函數
因爲須要開發者自行判斷統計腳本放置的位置,就會存在一些不許確的狀況,由於每一個人對首屏的理解不一樣工具
基於上面的分析,咱們近期嘗試了一些方案,試圖將首屏時間計算自動化,節省人力、並提升準確性。性能
對首屏時間的定義,每一個公司可能會有所不一樣,在本文中,首屏時間指的是:
若是頁面首屏有圖片
首屏時間 = 首屏圖片所有加載完畢的時刻 - window.performance.timing.navigationStart
若是頁面首屏沒有圖片
首屏時間 = 頁面處於穩定狀態前最後一次 dom 變化的時刻 - window.performance.timing.navigationStart
整體思路爲:
問題:按照怎樣的間隔打點?
問題:如何找出這個 T1?
下面,一個個解決上文中提到的問題:
問題:如何找出首屏處於穩定狀態的時刻 T1?
咱們將頁面從加載到渲染分爲兩大階段:1. 獲取數據;2. 數據獲取完畢,渲染頁面。
這個邏輯符合絕大部分的頁面邏輯:先獲取數據,再渲染頁面。
解決方案:
咱們認爲可能影響首屏的請求在 [第一個 xhr 請求發出的時刻,第一個 xhr 請求發出的時刻 + 1000ms]
的時間段內均已發出。
有些頁面的數據請求方式是串行的,可能通過兩個串聯的請求後首屏的數據才能加載。
影響首屏的請求可能也會以這樣的形式發出。
T1 = T1 + 300ms
,保證頁面接收數據後渲染完畢(300ms 用於一次渲染足夠了)。問題:按照怎樣的間隔打點?
你們都知道 MutationObserver 對象用於捕捉頁面 dom 變化,所以在腳本中,咱們使用了 MutationObserver 監聽 dom 變化,並在每次 dom 變化時觸發一次打點(統計該時刻首屏圖片信息)
setInterval 也能實現定時打點
MutationObserver 和 setInterval 組合
但 MutationObserver 回調函數的觸發時機開發者並不可控,有幾種狀況:
img
的 src
發生了變化或元素的 background-image
發生了變化,並不會觸發在 MutationObserver 的回調,致使統計失誤所以,咱們如今的方案是結合 MutationObserver 和 setInterval,在 MutationObserver 回調的間歇,啓動 setInterval,保證頁面加載過程當中打點間隔不會過長,提升統計準確率。
即便使用了上述複雜的打點與判斷,偏差仍然存在,那麼,偏差到底在哪裏?
以下圖所示:
不穩定狀態(1 images) 穩定狀態2(2 images) 穩定狀態1(2 images) | | | |________________________|_______________________| t1 t2 t3
按照上面的理論,咱們會取 t2
時刻爲能夠統計首屏的時刻,兩張圖片加載完成的時刻即爲首屏完成的時刻。
t2
和 t1
時刻差了 1 張圖片。
按照咱們的理論,首屏完成時間必定在 t2 以後的某個時刻 t2.n
。
而實際相差的那張圖片,何時加載完成的,咱們不得而知,可能在 t2
前已經加載完畢了,也可能已經發出請求,但還沒加載完畢。
偏差就在這裏,它總會存在。
但咱們須要統計的是在偏差能夠接受範圍內的首屏數據,根據在公司業務實踐的反饋來看,數據可靠性很高。
咱們也開源了這個小工具:
github: auto-compute-first-screen-time
npm: auto-compute-first-screen-time
歡迎小夥伴們使用,吐槽,改進。