1寫在前面

通常，我們在開發(fā)環(huán)境中進(jìn)行首屏?xí)r間測試，是通過在內(nèi)網(wǎng)中通過Chrome DevTools觀察首屏?xí)r間，這樣內(nèi)外網(wǎng)絡(luò)環(huán)境存在差異，導(dǎo)致測量的首屏?xí)r間也會有所不同。我們在開發(fā)中使用的是調(diào)試工具，而用戶是直接訪問的，兩者的訪問形式是不同的。觀察首屏?xí)r間的設(shè)備有多種，而真實(shí)的用戶人群不同，移動設(shè)備的型號和所處網(wǎng)絡(luò)環(huán)境也是各異的。

那么，如何了解用戶的首屏?xí)r間呢?大量用戶的首屏?xí)r間分布又是怎樣的呢?性能差的用戶首屏?xí)r間又是多少呢?

2手動采集辦法及優(yōu)缺點(diǎn)

所謂手動采集，一般就是通過埋點(diǎn)的方式進(jìn)行采集上報(bào)，如：我們要收集當(dāng)前頁面的用戶停留時(shí)間，就必須采集到打開頁面的時(shí)間和關(guān)閉或隱藏頁面的時(shí)間，再進(jìn)行計(jì)算得到停留時(shí)間并上報(bào)。

如果是電商列表頁面，瀑布流型的頁面，需要根據(jù)各個(gè)機(jī)型的首屏位置，估算出一個(gè)平均的首屏位置，然后進(jìn)行打點(diǎn)上報(bào)。

手動采集的兼容性強(qiáng)，可以隨著情況而進(jìn)行變動，其次可以去中心化，各個(gè)業(yè)務(wù)模塊單獨(dú)負(fù)責(zé)自己的打點(diǎn)代碼，有問題時(shí)業(yè)務(wù)程序員去排查問題即可。但是手動采集也存在一些問題，容易與業(yè)務(wù)代碼嚴(yán)重耦合，它的覆蓋率不足，業(yè)務(wù)程序員一旦忙起來，性能優(yōu)化方案的實(shí)施就會延遲排后。

3自動化采集的辦法及優(yōu)點(diǎn)

自動化采集，即引入一段通用的代碼來做首屏?xí)r間自動化采集，引入過程中，除了必要的配置外不需要做其他事情。獨(dú)立性強(qiáng)，接入過程更加自動化，可以由一個(gè)公共團(tuán)隊(duì)來開發(fā)，試點(diǎn)后進(jìn)行推廣到各個(gè)業(yè)務(wù)團(tuán)隊(duì)。但是，有些個(gè)性化需求是無法得到滿足的，因?yàn)樵诠ぷ髦锌倳龅揭恍┨厥鈽I(yè)務(wù)場景，會遇到難以實(shí)施自動化采集的情況。

4服務(wù)端模板業(yè)務(wù)下的采集方案

有人會說現(xiàn)在的前端開發(fā)不都是采用web框架進(jìn)行開發(fā)嗎，為啥還會涉及到服務(wù)器模板呢。那是因?yàn)樵谝恍〣端業(yè)務(wù)的公司用的還是服務(wù)端模板，如Velocity、Smarty等，比如說微前端框架SSR也是用的服務(wù)端模板。

之所以會出現(xiàn)這種情況，這是因?yàn)楹蠖吮容^重、前端偏配合，出于效率考慮前后端并沒有進(jìn)行解耦。這時(shí)候如果使用現(xiàn)在流行的web前端框架vue/react，這無疑就會增加學(xué)習(xí)成本。

使用瀏覽器提供的DOMContentLoaded接口來采集首屏?xí)r間點(diǎn)，具體的思路是：當(dāng)頁面中的HTML元素被加載和解析完成后，DOMContentLoaded事件會被觸發(fā)，首屏?xí)r間=DOMContentLoaded時(shí)間=DOMContentLoadedEventEnd-fetchStart時(shí)間。

當(dāng)然這種采集方法不能用于SPA單頁面應(yīng)用業(yè)務(wù)場景，這是因?yàn)樵谑褂肞erformance API接口采集的首屏?xí)r間可能是1106ms。而實(shí)際首屏?xí)r間可能就是1976ms。在SPA單頁面中，用戶請求一個(gè)頁面時(shí)，頁面會先加載index.html，加載完成后就會觸發(fā)DOMContentLoaded和load。頁面會相關(guān)腳本資源并通過axios異步請求數(shù)據(jù)，使用數(shù)據(jù)渲染頁面主題部分，這個(gè)時(shí)候首屏才渲染完成。SPA的流行讓Performance API接口失去了原先的意義，那么，這種情況下應(yīng)該如何采集首屏指標(biāo)呢?

當(dāng)然，我們的解決方案是采用MutationObeserver采集首屏?xí)r間。

5單頁面SPA應(yīng)用業(yè)務(wù)場景下的采集方法

如果一個(gè)首屏頁面的內(nèi)容沒有被組件化，那么首屏?xí)r間就無法被統(tǒng)計(jì)到，除非各個(gè)業(yè)務(wù)都制定一套組件標(biāo)準(zhǔn)，首屏內(nèi)容必須封裝成組件。前面也知道onload的時(shí)間也并非最終時(shí)間，可能在onlaod階段，首屏還沒加載完。其次，沒有考慮到首屏是張圖片的情況，首屏雖然加載完成了，但是圖片是異步的，圖片并沒有進(jìn)行加載。

我們想如果能夠在首屏渲染過程中，把各個(gè)資源的加載時(shí)間記錄到日志中，后續(xù)再通過分析，確定某個(gè)資源加載完的時(shí)間，那么就是首屏?xí)r間。

MutationObeserver接口提供了監(jiān)督對DOM樹所做更改的能力，它被設(shè)計(jì)為舊的MutationEvents功能的替代品，該功能是DOM3 Events規(guī)范的一部分。

當(dāng)用戶進(jìn)入頁面時(shí)，我們可以使用MutationObeserver監(jiān)控DOM元素，當(dāng)DOM元素發(fā)生變化時(shí)，程序會標(biāo)記變化的元素，記錄時(shí)間點(diǎn)和分?jǐn)?shù)，儲存在數(shù)組中。首屏指標(biāo)采集到某些條件時(shí)，首屏渲染已經(jīng)結(jié)束了，我們需要考慮到首屏采集終止的條件。

遞歸遍歷DOM元素及其子元素，根據(jù)子元素所在層級設(shè)定元素權(quán)重，比如：頁面DOM元素的第一層設(shè)置為1，當(dāng)其被渲染時(shí)得分為1，每增加一個(gè)元素層級權(quán)重增加0.5，當(dāng)?shù)谖鍖蛹壴氐臋?quán)重就為3.5，渲染時(shí)給出對應(yīng)分?jǐn)?shù)。根據(jù)前面統(tǒng)計(jì)到的元素層級得分，計(jì)算元素的分?jǐn)?shù)變化率，獲取變化率最大點(diǎn)對應(yīng)的分?jǐn)?shù)，然后找到該分?jǐn)?shù)對應(yīng)的時(shí)間，即為首屏?xí)r間。

1. function CScor(el, tiers, parentScore){ 
2.   let score = 0; 
3.   const tagName = el.tagName; 
4.   // 判斷當(dāng)前的標(biāo)簽元素是否為指定的標(biāo)簽元素 
5.   if(!filterTagNameInTagNames(tagName)){ 
6.     const childrenLen = el.children ? el.children.length : 0; 
7.     // 判讀子元素的長度是否大于0 
8.     if(childrenLen>0){ 
9.       for(let childs = el.children, len = childrenLen-1; len >= 0; len--){ 
10.         score += calculateScore(childs[len],tiers+1,score>0) 
11.       } 
12.     } 
13.     // 判斷分?jǐn)?shù)是否小于等于0，且父元素的分?jǐn)?shù)為0 
14.     if(score<= 0&& !parentScore){ 
15.       if(!(el.getBoundingClintRect&& el.getBoundingClintRect().top<WH)) return 0 
16.     } 
17.     score += 1 + 0.5 * tiers; 
18.   } 
19.   return score 
20. } 
21.  
22. function filterTagNameInTagNames(tagName){ 
23.   return ["SCRIPT","STYLE","META","HEAD"].some(tag=>tag===tagName) 
24. } 
25.  
26. calFinalScore(){ 
27.   try { 
28.     if(this.sendMark) return; 
29.     const time = Date.now() - window.performance.timing.fetchStart; 
30.     let isCheckFMP = time > 30000 || SCORE_ITEMS && SCORE_ITEMS.length > 4 && time - (SCORE_ITEMS && SCORE_ITEMS.length && SCORE_ITEMS[SCORE_ITEMS.length-1].t || 0) > 2 * CHECK_INTERVAL || ( 
31.       SCORE_ITEMS.length > 10 && window.performance.timing.loadEventEnd !== 0 && 
32.       SCORE_ITEMS[SCORE_ITEMS.length-1].score === SCORE_ITEMS[SCORE_ITEMS.length - 1].score 
33.     ); 
34.     if(this.observer && isCheckFMP){ 
35.       this.observer.disconnect 
36.       // 取FMP時(shí)間，默認(rèn)是30001大于30s會自動被過濾 
37.       this.fmp = record && record.t || 30001 
38.       try { 
39.         this.checkImgs(document.body) 
40.         let max = Math.max(...this.imgs.map(element=>{ 
41.           if(/^(\/\/)/.test(element)) element = "https:" + element 
42.           try { 
43.             return window.performance.getEntriesByName(element)[0].responseEnd || 0 
44.           } catch (error) { 
45.             return 0  
46.           } 
47.         })) 
48.       } catch (error) { 
49.         return 
50.       } 
51.     } 
52.   } catch (error) { 
53.     return 
54.   } 
55. } 

如果頁面里包括圖片，使用上面的首屏指標(biāo)采集方案，結(jié)果準(zhǔn)確嗎?答案是不準(zhǔn)確的。上述的計(jì)算邏輯主要針對的是DOM元素而做的，圖片加載過程是異步，圖片容器(圖片的DOM元素)和內(nèi)容的加載是分開的，當(dāng)容器加載出來時(shí)，內(nèi)容還沒出來，一定要確保內(nèi)容加載出來，才算是首屏。

進(jìn)行個(gè)歸納，通常計(jì)算首屏?xí)r間的方法有：

• 首屏模塊標(biāo)記法
• 統(tǒng)計(jì)首屏內(nèi)加載最慢的圖片
• 自定義首屏

首屏模塊標(biāo)簽標(biāo)記法

在首屏模塊標(biāo)簽標(biāo)記法中，首屏?xí)r間等于firstScreen - performance.timing.navigationStart;。但是在實(shí)際業(yè)務(wù)中，能夠使用首屏模塊標(biāo)簽標(biāo)記法的情況比較少，大多數(shù)頁面都需要通過接口拉取數(shù)據(jù)才能完整展示，因此我們會使用JavaScript 腳本來判斷首屏頁面內(nèi)容加載情況。

1. <!DOCTYPE html> 
2. <html lang="en"> 
3. <head> 
4.   <meta charset="UTF-8"> 
5.   <title>首屏</title> 
6.   <script type="text/javascript"> 
7.     window.pageStartTime = Date.now(); 
8.   </script> 
9.   <link rel="stylesheet" href="common.css"> 
10.   <link rel="stylesheet" href="page.css"> 
11. </head> 
12. <body> 
13.   <!-- 首屏可見模塊1 --> 
14.   <div class="module-1"></div> 
15.   <!-- 首屏可見模塊2 --> 
16.   <div class="module-2"></div> 
17.   <script type="text/javascript"> 
18.     window.firstScreen = Date.now(); 
19.   </script> 
20.   <!-- 首屏不可見模塊3 --> 
21.   <div class="module-3"></div> 
22.     <!-- 首屏不可見模塊4 --> 
23.   <div class="module-4"></div> 
24. </body> 
25. </html> 

統(tǒng)計(jì)首屏內(nèi)圖片完成加載的時(shí)間

在實(shí)際進(jìn)行首屏加載中，加載最慢的資源文件是圖片，對此我們可以將加載最慢的圖片文件的時(shí)間作為首屏?xí)r間。這是因?yàn)樵跒g覽器發(fā)起HTTP請求，在頁面中建立TCP連接，但是每個(gè)頁面所能建立的連接數(shù)又是有限的，使得并不能一次性將所有的圖片都能進(jìn)行下載和展示。

基于此種情況，我們可以在頁面DOM樹構(gòu)建完成后去遍歷首屏內(nèi)所有的圖片標(biāo)簽，并對每個(gè)圖片標(biāo)簽的onload事件進(jìn)行監(jiān)聽，從而計(jì)算得到所有圖片中加載時(shí)間的最大值。這樣就得到首屏?xí)r間=加載最慢的圖片的時(shí)間點(diǎn) - performance.timing.navigationStart。

自定義模塊內(nèi)容計(jì)算法

由于在統(tǒng)計(jì)首屏內(nèi)遍歷圖片標(biāo)簽列表得到最大加載時(shí)間比較復(fù)雜，對此在業(yè)務(wù)中可以通過自定義模塊內(nèi)容，來簡化計(jì)算首屏?xí)r間。如下面的做法：

忽略圖片等資源加載情況，只考慮頁面主要DOM

只考慮首屏的主要模塊，而不是嚴(yán)格意義首屏線以上的所有內(nèi)容

6參考文章

《前端性能優(yōu)化方法與實(shí)踐》

《前端優(yōu)化-如何計(jì)算白屏和首屏?xí)r間》

7寫在最后

本文主要介紹了首屏指標(biāo)采集相關(guān)的內(nèi)容，這種性能采集方案靠譜嗎?當(dāng)前的互聯(lián)網(wǎng)大廠又在使用什么采集方案呢?就目前而言，上面介紹的是當(dāng)前應(yīng)用的最好的首屏指標(biāo)采集方案，兼容了單頁面應(yīng)用和服務(wù)端模板的頁面。

原文鏈接：https://mp.weixin.qq.com/s/6bf8kgzCt3akAiZJYiAFNw