精確并自動化地獲取頁面首屏時間

dreambei 發布于2019-08-22 15:05 / 2891人閱讀

摘要：如何自動獲取首屏時間作者劉遠洋公司微店前端團隊日期本文發表在微店前端團隊背景在前端性能數據的獲取方法上，現在業內大多使用手動埋點的方式，即在代碼中，人工判斷首屏完成的位置，并在該處添加首屏記錄的代碼，類似這樣。

如何自動獲取首屏時間

作者：劉遠洋

公司：微店 - 前端團隊

日期：2018-03-05

本文發表在微店前端團隊 blog

背景

在前端性能數據的獲取方法上，現在業內大多使用手動埋點的方式，即在代碼中，人工判斷首屏完成的位置，并在該處添加首屏記錄的代碼，類似：firstscreen.report() 這樣。

這樣做的簡單省事，但缺點也很明顯：

和業務代碼混用

通用的監控需求混入了業務代碼中

覆蓋不完整

需要頁面開發者自覺手動添加埋點代碼，在業務中埋點覆蓋率不一定能達到 100%

準確性不一定高

由于需要開發者自行判斷統計腳本放置的位置，就會存在一些不準確的情況，因為每個人對首屏的理解不同

基于上面的分析，我們近期嘗試了一些方案，試圖將首屏時間計算自動化，節省人力、并提高準確性。

定義

對首屏時間的定義，每個公司可能會有所不同，在本文中，首屏時間指的是：

如果頁面首屏有圖片

首屏時間 = 首屏圖片全部加載完畢的時刻 - window.performance.timing.navigationStart

如果頁面首屏沒有圖片

首屏時間 = 頁面處于穩定狀態前最后一次 dom 變化的時刻 - window.performance.timing.navigationStart

實現原理

總體思路為：

從頁面加載開始，按照一定的間隔打點，不斷記錄各個時刻下頁面首屏圖片列表和其他信息

問題：按照怎樣的間隔打點？

找出頁面首屏處于穩定狀態的時刻 T1（到這個時刻為止，頁面首屏可能已經穩定了一段時間）

問題：如何找出這個 T1？

以 T1 時刻的首屏圖片數量為準，向前倒推，找到所有打點中最后一次和 T1 時刻首屏圖片一致的打點時刻 T2

統計 T2 時刻的所有圖片加載完成時間 T3

T3 即為首屏完成的時刻，進行上報

下面，一個個解決上文中提到的問題：

問題：如何找出首屏處于穩定狀態的時刻 T1？

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

這個邏輯符合絕大部分的頁面邏輯：先獲取數據，再渲染頁面。

解決方案：

通過 AOP 切面方式監聽 XHR 的 send 對象，抓取頁面中的第一個 XHR 請求，以第一個 XHR 請求發出的時刻為起點，統計在 1000ms 以內所有發出的請求到數組 Request 中。

我們認為可能影響首屏的請求在 [第一個 xhr 請求發出的時刻，第一個 xhr 請求發出的時刻 + 1000ms] 的時間段內均已發出。

針對串聯型的請求（即下一個請求依賴上一個請求的返回數據），同時統計每個請求返回后，500ms 以內新發出的請求到數組 Request 中。

有些頁面的數據請求方式是串行的，可能經過兩個串聯的請求后首屏的數據才能加載。

影響首屏的請求可能也會以這樣的形式發出。

數組 Request 中統計到的請求，基本包含了所有影響首屏的數據請求，同時也包含了部分不影響首屏的數據請求。

針對上述統計到的請求，找到所有數據返回的時刻 T1，然后，T1 = T1 + 300ms，保證頁面接收數據后渲染完畢（300ms 用于一次渲染足夠了）。

此時的 T1 時刻，頁面首屏被認為處于穩定狀態。

問題：按照怎樣的間隔打點？

MutationObserver

大家都知道 MutationObserver 對象用于捕捉頁面 dom 變化，因此在腳本中，我們使用了 MutationObserver 監聽 dom 變化，并在每次 dom 變化時觸發一次打點（統計該時刻首屏圖片信息）

setInterval

setInterval 也能實現定時打點

MutationObserver 和 setInterval 組合

但 MutationObserver 回調函數的觸發時機開發者并不可控，有幾種情況：

兩次回調之間可能距離幾百毫秒甚至 1秒多，導致統計誤差較大

某些情況下，dom 不再變化，但頁面元素中，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 前已經加載完畢了，也可能已經發出請求，但還沒加載完畢。

誤差就在這里，它總會存在。

但我們需要統計的是在誤差可以接受范圍內的首屏數據，根據在公司業務實踐的反饋來看，數據可靠性很高。

Talk is cheap, show me the code

我們也開源了這個小工具：

github: auto-compute-first-screen-time

npm: auto-compute-first-screen-time

歡迎小伙伴們使用，吐槽，改進。

GPU云服務器云服務器 linux自動備份數據并郵件 webrtc 獲取數據并傳輸通過imsi獲取歸屬地 asp獲取ip歸屬地

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/93158.html

騰訊祭出大招VasSonic，讓你的H5頁面首屏秒開

摘要：經過一系列優化后，在平臺上，點擊到頁面首屏展示的耗時從平均多降低為，優化以上。而現在頁面為了更好地為用戶推薦喜歡的內容，我們后臺引入機器學習和隨機算法來做智能個性化推薦。另外還有部分的內容是隨機算法推薦的。 VasSonic成長歷程前言 2017.8.8 14時，SNG增值產品部Vas團隊研發的輕量級高性能Hybrid框架VasSonic通過了公司最終審核，作為騰訊開源組件分享給大...

xzavier 2019-08-01 17:25 評論0 收藏0
關于首屏時間采集自動化的解決方案

摘要：關于首屏首屏時間是指從轉向該頁面到屏幕中該頁面所有內容都可見時的時間。如在事件處理函數中，計算高度，如果大于屏幕高度則意味著首屏的結構已渲染完畢，開始計算首屏時間。關于首屏首屏時間是指從轉向該頁面到屏幕中該頁面所有內容都可見時的時間。已經有太多的關于首屏時間的計算，在本文中并不重復闡述這些已經被提出或者實現的方案，而旨在探索與討論更多的首屏自動化采集方案，擴大思考范圍，你我思想之間...

Rindia 2019-08-01 18:28 評論0 收藏0
關于首屏時間采集自動化的解決方案

摘要：關于首屏首屏時間是指從轉向該頁面到屏幕中該頁面所有內容都可見時的時間。如在事件處理函數中，計算高度，如果大于屏幕高度則意味著首屏的結構已渲染完畢，開始計算首屏時間。關于首屏首屏時間是指從轉向該頁面到屏幕中該頁面所有內容都可見時的時間。已經有太多的關于首屏時間的計算，在本文中并不重復闡述這些已經被提出或者實現的方案，而旨在探索與討論更多的首屏自動化采集方案，擴大思考范圍，你我思想之間...

1treeS 2019-08-22 14:05 評論0 收藏0