摘要：如何自動(dòng)獲取首屏?xí)r間作者劉遠(yuǎn)洋公司微店前端團(tuán)隊(duì)日期本文發(fā)表在微店前端團(tuán)隊(duì)背景在前端性能數(shù)據(jù)的獲取方法上，現(xiàn)在業(yè)內(nèi)大多使用手動(dòng)埋點(diǎn)的方式，即在代碼中，人工判斷首屏完成的位置，并在該處添加首屏記錄的代碼，類(lèi)似這樣。

作者：劉遠(yuǎn)洋

公司：微店 - 前端團(tuán)隊(duì)

日期：2018-03-05

本文發(fā)表在 微店前端團(tuán)隊(duì) blog

在前端性能數(shù)據(jù)的獲取方法上，現(xiàn)在業(yè)內(nèi)大多使用手動(dòng)埋點(diǎn)的方式，即在代碼中，人工判斷首屏完成的位置，并在該處添加首屏記錄的代碼，類(lèi)似：firstscreen.report() 這樣。

這樣做的簡(jiǎn)單省事，但缺點(diǎn)也很明顯：

和業(yè)務(wù)代碼混用

通用的監(jiān)控需求混入了業(yè)務(wù)代碼中

覆蓋不完整

需要頁(yè)面開(kāi)發(fā)者自覺(jué)手動(dòng)添加埋點(diǎn)代碼，在業(yè)務(wù)中埋點(diǎn)覆蓋率不一定能達(dá)到 100%

準(zhǔn)確性不一定高

由于需要開(kāi)發(fā)者自行判斷統(tǒng)計(jì)腳本放置的位置，就會(huì)存在一些不準(zhǔn)確的情況，因?yàn)槊總€(gè)人對(duì)首屏的理解不同

基于上面的分析，我們近期嘗試了一些方案，試圖將首屏?xí)r間計(jì)算自動(dòng)化，節(jié)省人力、并提高準(zhǔn)確性。

對(duì)首屏?xí)r間的定義，每個(gè)公司可能會(huì)有所不同，在本文中，首屏?xí)r間指的是：

如果頁(yè)面首屏有圖片

首屏?xí)r間 = 首屏圖片全部加載完畢的時(shí)刻 - window.performance.timing.navigationStart

如果頁(yè)面首屏沒(méi)有圖片

首屏?xí)r間 = 頁(yè)面處于穩(wěn)定狀態(tài)前最后一次 dom 變化的時(shí)刻 - window.performance.timing.navigationStart

總體思路為：

從頁(yè)面加載開(kāi)始，按照一定的間隔打點(diǎn)，不斷記錄各個(gè)時(shí)刻下頁(yè)面首屏圖片列表和其他信息

問(wèn)題：按照怎樣的間隔打點(diǎn)？

找出頁(yè)面首屏處于穩(wěn)定狀態(tài)的時(shí)刻 T1（到這個(gè)時(shí)刻為止，頁(yè)面首屏可能已經(jīng)穩(wěn)定了一段時(shí)間）

問(wèn)題：如何找出這個(gè) T1？

以 T1 時(shí)刻的首屏圖片數(shù)量為準(zhǔn)，向前倒推，找到所有打點(diǎn)中最后一次和 T1 時(shí)刻首屏圖片一致的打點(diǎn)時(shí)刻 T2

統(tǒng)計(jì) T2 時(shí)刻的所有圖片加載完成時(shí)間 T3

T3 即為首屏完成的時(shí)刻，進(jìn)行上報(bào)

下面，一個(gè)個(gè)解決上文中提到的問(wèn)題：

問(wèn)題：如何找出首屏處于穩(wěn)定狀態(tài)的時(shí)刻 T1？

我們將頁(yè)面從加載到渲染分為兩大階段：1. 獲取數(shù)據(jù)；2. 數(shù)據(jù)獲取完畢，渲染頁(yè)面。

這個(gè)邏輯符合絕大部分的頁(yè)面邏輯：先獲取數(shù)據(jù)，再渲染頁(yè)面。

解決方案：

通過(guò) AOP 切面方式監(jiān)聽(tīng) XHR 的 send 對(duì)象，抓取頁(yè)面中的第一個(gè) XHR 請(qǐng)求，以第一個(gè) XHR 請(qǐng)求發(fā)出的時(shí)刻為起點(diǎn)，統(tǒng)計(jì)在 1000ms 以內(nèi)所有發(fā)出的請(qǐng)求到數(shù)組 Request 中。

我們認(rèn)為可能影響首屏的請(qǐng)求在 [第一個(gè) xhr 請(qǐng)求發(fā)出的時(shí)刻，第一個(gè) xhr 請(qǐng)求發(fā)出的時(shí)刻 + 1000ms] 的時(shí)間段內(nèi)均已發(fā)出。

針對(duì)串聯(lián)型的請(qǐng)求（即下一個(gè)請(qǐng)求依賴上一個(gè)請(qǐng)求的返回?cái)?shù)據(jù)），同時(shí)統(tǒng)計(jì)每個(gè)請(qǐng)求返回后，500ms 以內(nèi)新發(fā)出的請(qǐng)求到數(shù)組 Request 中。

有些頁(yè)面的數(shù)據(jù)請(qǐng)求方式是串行的，可能經(jīng)過(guò)兩個(gè)串聯(lián)的請(qǐng)求后首屏的數(shù)據(jù)才能加載。

影響首屏的請(qǐng)求可能也會(huì)以這樣的形式發(fā)出。

數(shù)組 Request 中統(tǒng)計(jì)到的請(qǐng)求，基本包含了所有影響首屏的數(shù)據(jù)請(qǐng)求，同時(shí)也包含了部分不影響首屏的數(shù)據(jù)請(qǐng)求。

針對(duì)上述統(tǒng)計(jì)到的請(qǐng)求，找到所有數(shù)據(jù)返回的時(shí)刻 T1，然后，T1 = T1 + 300ms，保證頁(yè)面接收數(shù)據(jù)后渲染完畢（300ms 用于一次渲染足夠了）。

此時(shí)的 T1 時(shí)刻，頁(yè)面首屏被認(rèn)為處于穩(wěn)定狀態(tài)。

問(wèn)題：按照怎樣的間隔打點(diǎn)？

MutationObserver

大家都知道 MutationObserver 對(duì)象用于捕捉頁(yè)面 dom 變化，因此在腳本中，我們使用了 MutationObserver 監(jiān)聽(tīng) dom 變化，并在每次 dom 變化時(shí)觸發(fā)一次打點(diǎn)（統(tǒng)計(jì)該時(shí)刻首屏圖片信息）

setInterval

setInterval 也能實(shí)現(xiàn)定時(shí)打點(diǎn)

MutationObserver 和 setInterval 組合

但 MutationObserver 回調(diào)函數(shù)的觸發(fā)時(shí)機(jī)開(kāi)發(fā)者并不可控，有幾種情況：

兩次回調(diào)之間可能距離幾百毫秒甚至 1秒多，導(dǎo)致統(tǒng)計(jì)誤差較大

某些情況下，dom 不再變化，但頁(yè)面元素中，img 的 src 發(fā)生了變化或元素的 background-image 發(fā)生了變化，并不會(huì)觸發(fā)在 MutationObserver 的回調(diào)，導(dǎo)致統(tǒng)計(jì)失誤

因此，我們現(xiàn)在的方案是結(jié)合 MutationObserver 和 setInterval，在 MutationObserver 回調(diào)的間歇，啟動(dòng) setInterval，保證頁(yè)面加載過(guò)程中打點(diǎn)間隔不會(huì)過(guò)長(zhǎng)，提高統(tǒng)計(jì)準(zhǔn)確率。

即使使用了上述復(fù)雜的打點(diǎn)與判斷，誤差仍然存在，那么，誤差到底在哪里？

如下圖所示：

不穩(wěn)定狀態(tài)（1 images）   穩(wěn)定狀態(tài)2（2 images）      穩(wěn)定狀態(tài)1（2 images）
    |                        |                       |
    |________________________|_______________________|
    t1                       t2                      t3

按照上面的理論，我們會(huì)取 t2 時(shí)刻為可以統(tǒng)計(jì)首屏的時(shí)刻，兩張圖片加載完成的時(shí)刻即為首屏完成的時(shí)刻。

t2 和 t1 時(shí)刻差了 1 張圖片。

按照我們的理論，首屏完成時(shí)間一定在 t2 之后的某個(gè)時(shí)刻 t2.n。

而實(shí)際相差的那張圖片，什么時(shí)候加載完成的，我們不得而知，可能在 t2 前已經(jīng)加載完畢了，也可能已經(jīng)發(fā)出請(qǐng)求，但還沒(méi)加載完畢。

誤差就在這里，它總會(huì)存在。

但我們需要統(tǒng)計(jì)的是在誤差可以接受范圍內(nèi)的首屏數(shù)據(jù)，根據(jù)在公司業(yè)務(wù)實(shí)踐的反饋來(lái)看，數(shù)據(jù)可靠性很高。

我們也開(kāi)源了這個(gè)小工具：

github: auto-compute-first-screen-time

npm: auto-compute-first-screen-time

歡迎小伙伴們使用，吐槽，改進(jìn)。