背景

由于轉(zhuǎn)轉(zhuǎn)前端業(yè)務(wù)方向主要偏向于 C 端，比如 App端內(nèi) H5、 小程序內(nèi) H5 等，并且技術(shù)棧以 Hybrid 為主（承載容器為轉(zhuǎn)轉(zhuǎn)標(biāo)準(zhǔn)化webview）。但是，近些年隨著業(yè)務(wù)不斷擴(kuò)大，逐漸出現(xiàn)了如乾數(shù)據(jù)平臺、行星平臺等 專門服務(wù) B 端的FE項(xiàng)目。但是沒有相關(guān)性能數(shù)據(jù)來作為參考支撐，比如需要分析用戶體驗(yàn)質(zhì)量；分析現(xiàn)有頁面性能缺陷以及后續(xù)需要做性能優(yōu)化的方向等。因此，需要一款符合轉(zhuǎn)轉(zhuǎn)內(nèi)部埋點(diǎn)上報(bào)體系的 PC 端項(xiàng)目網(wǎng)頁的性能統(tǒng)計(jì)平臺。

B 端性能統(tǒng)計(jì)面臨的問題

由于內(nèi)部性能埋點(diǎn)統(tǒng)計(jì)體系不支持分批/分段上報(bào)，每個(gè) Router 都需要作為一個(gè)單獨(dú)的頁面進(jìn)行一次性的性能數(shù)據(jù)上報(bào)。在 B 端，一些新的指標(biāo)需要支持和特殊處理。因此，在數(shù)據(jù)采集統(tǒng)計(jì)方面，我們會遇到以下幾個(gè)問題。

1. SPA Router 問題 轉(zhuǎn)轉(zhuǎn)內(nèi)部 C 端項(xiàng)目主要采用 hybrid 技術(shù)棧，因此不需要對 SPA 項(xiàng)目路由做特殊處理（因?yàn)槊看味奸_啟一個(gè) webview，類似于多頁面應(yīng)用應(yīng)用場景）。但是，基于 React 技術(shù)棧的 B 端項(xiàng)目是 SPA 項(xiàng)目，為了方便統(tǒng)計(jì)每個(gè) Router 頁面的性能數(shù)據(jù)，我們需要對每個(gè) Router 頁面的加載進(jìn)行一些特殊處理。
2. SPA 資源統(tǒng)計(jì)問題 現(xiàn)在的前端 SPA 項(xiàng)目一般都會通過異步加載頁面資源的方式，進(jìn)行頁面打包體積的優(yōu)化，以提升頁面首屏性能。因此，在進(jìn)行資源統(tǒng)計(jì)時(shí)，我們需要單獨(dú)對相應(yīng)的 Router 頁面的加載資源進(jìn)行統(tǒng)計(jì)處理。
3. B 端指標(biāo)定義問題 轉(zhuǎn)轉(zhuǎn) B 端性能統(tǒng)計(jì)主要參考核心指標(biāo)：白屏、首屏、完全加載。頁面性能分?jǐn)?shù)評估也主要基于這三個(gè)指標(biāo)進(jìn)行加權(quán)計(jì)算。但是，在 Router 頁面加載時(shí)，我們會遇到核心性能指標(biāo)無法直接獲取的問題，因?yàn)?Router 切換并不會產(chǎn)生頁面的 load，而只是 div 的顯示隱藏。當(dāng)然了，還需要其他 B 端特有的業(yè)務(wù)標(biāo)識定義，這里不一一列舉。

主要內(nèi)容

1. 性能指標(biāo)定義

定義好哪些性能指標(biāo)需要上報(bào)，是做好一個(gè)完善的采集性能數(shù)據(jù)采集 sdk 的前提條件，經(jīng)過分析主要將指標(biāo)分為兩類：1. 純 H5 頁面性能指標(biāo) 2. 頁面相關(guān)業(yè)務(wù)性指標(biāo)。

• 純 H5 頁面性能指標(biāo)

1. 性能核心指標(biāo)主要包括：白屏?xí)r間 、 首屏?xí)r間、 頁面完全加載時(shí)間，以及新增的用戶體驗(yàn)指標(biāo) LCP、 FID、 CLS 。
2. 輔助性性能指標(biāo)包括：DNS 解析 、請求響應(yīng)時(shí)間、 DOM開始構(gòu)建時(shí)間、 頁面可交互時(shí)間、 DOM構(gòu)建完成時(shí)間、 網(wǎng)絡(luò)速度、 各類靜態(tài)資源耗時(shí)、 ajax請求耗時(shí)、 LongTask 等等。

以上提到的絕大部分指標(biāo)，可以通過瀏覽器提供的 PerformanceNavigationTiming PerformanceResourceTiming API 和 谷歌團(tuán)隊(duì)提供的 web-vitals 工具函數(shù)很方便的進(jìn)行獲取和計(jì)算。

• 業(yè)務(wù)性相關(guān)指標(biāo):

所謂業(yè)務(wù)性指標(biāo)，主要是作為查詢分析的一些要素，比如 我們想查詢某個(gè)業(yè)務(wù)線的某個(gè)項(xiàng)目的某個(gè)頁面在某個(gè)平臺下某個(gè)性能指標(biāo)的表現(xiàn)如何？那么就需要一些非頁面性能本身的業(yè)務(wù)要素指標(biāo)進(jìn)行定義和上報(bào)統(tǒng)計(jì)。

業(yè)務(wù)指標(biāo)主要包括：actiontype 埋點(diǎn)類型標(biāo)識 、 pagetype 業(yè)務(wù)線/項(xiàng)目標(biāo)識、pageid 頁面標(biāo)識 、 clientType 端信息、 pagestate 頁面狀態(tài)、pageurl 頁面url、 cookieid 用戶id、 fromType 來源、 loadcnt 加載次數(shù) 等等。

PS: web-vitals 由于在蘋果和低版本安卓的兼容性存在問題，因此沒有在 C 端作為一個(gè)必選項(xiàng)，但 B 端用戶絕大多數(shù)使用 chromium 內(nèi)核瀏覽器，所以大膽的將 web-vitals 納入采集指標(biāo)中

2. 指標(biāo)數(shù)據(jù)的獲取與上報(bào)

上面進(jìn)行了各種指標(biāo)的定義，那么如何高效有序的接入到轉(zhuǎn)轉(zhuǎn)埋點(diǎn)體系內(nèi)進(jìn)行上報(bào)統(tǒng)計(jì)呢？轉(zhuǎn)轉(zhuǎn)內(nèi)部其實(shí)已經(jīng)有了 C 端埋點(diǎn)體系，其實(shí)只需要按照一定的規(guī)則進(jìn)行接入即可，主要是性能平臺B端項(xiàng)目需要的字段和后端已有日志表結(jié)構(gòu)做好關(guān)系映射和擴(kuò)展。

為了解決上面提到B端項(xiàng)目的特有問題，以及滿足上述提到所有性能指標(biāo)、業(yè)務(wù)指標(biāo)都可以很優(yōu)雅的進(jìn)行上報(bào)統(tǒng)計(jì)，方便在代碼層面更好的進(jìn)行結(jié)構(gòu)上的解耦，并且盡量做到性能計(jì)算統(tǒng)計(jì)相關(guān)程序不影響頁面本身的性能，在技術(shù)實(shí)現(xiàn)設(shè)計(jì)層我們把上面的指標(biāo)做了一些分類，比如 同步計(jì)算指標(biāo)（基礎(chǔ)業(yè)務(wù)同步指標(biāo)、基礎(chǔ)性能資源同步指標(biāo)）、異步計(jì)算指標(biāo)（性能異步指標(biāo)、后置異步指標(biāo)）等。具體如下圖所示。

技術(shù)層面指標(biāo)分類

下面詳細(xì)介紹一下一些關(guān)鍵邏輯是怎么處理的？各類性能指標(biāo)具體是怎么計(jì)算的？下面列出了部分指標(biāo)怎么獲取和計(jì)算的關(guān)鍵代碼。

SPA 項(xiàng)目的路由頁面的攔截關(guān)鍵邏輯：

const hackRouter = () => {
  if (!window?.history?.pushState) {
    return;
  }
  // 瀏覽器的歷史記錄發(fā)生變化時(shí)被觸發(fā), 導(dǎo)航前進(jìn)、后退
  const oldOnPopState = window.onpopstate;
  window.onpopstate = function(this: WindowEventHandlers, ...args: any[]): any {
    const to = window.location.href;
    const from = lastHref;
    lastHref = to;
    // 通知訂閱的回調(diào)
    triggerHandlers('history', {
      from,
      to
    });
    if (oldOnPopState) {
      try {
        return oldOnPopState.apply(this, args);
      } catch (e) {}
    }
  };

  // history pushState 或 replaceState 觸發(fā)，通過 history api 方式
  const wrapHistoryFn = (type: 'pushState'|'replaceState') => {
    const originalHistoryFunction = window.history[type]
    return function(this: History, ...args: any[]): void {
      const url = args.length > 2 ? args[2] : undefined;
      if (url) {
        // coerce to string (this is what pushState does)
        const from = lastHref;
        const to = String(url);
        lastHref = to;
        // 通知訂閱的回調(diào)
        triggerHandlers('history', {
          from,
          to
        });
      }
      return originalHistoryFunction.apply(this, args);
    };
  };
  window.history.pushState = wrapHistoryFn("pushState");
  window.history.replaceState = wrapHistoryFn("replaceState");
}

性能基礎(chǔ)指標(biāo)的獲取相關(guān)代碼：

// 獲取 PerformanceTiming 相關(guān)數(shù)據(jù)
export const getPerformanceTimingData = (task: TaskTypes) => {
  if (!window?.performance?.timing) return {}
  const { metrics } = task;
  const { state } = task.ctx;
  const ptiming = performance.timing;
  // 默認(rèn)為 -1 方便過濾無效值
  const result = {
    blankTime: -1,
    dnsTime: -1,
    httpTime: -1,
    domTime: -1,
    domReady: -1,
    // ...
  }
  // 頁面加載狀態(tài)
  if(state === 'pageload') {
    // ...
    // 白屏
    result.blankTime = fix(ptiming.responseStart - ptiming.navigationStart);
    // DNS查詢
    result.dnsTime = fix(ptiming.domainLookupEnd - ptiming.domainLookupStart);
    // HTTP請求
    result.httpTime = fix(ptiming.responseEnd - ptiming.responseStart);
    // 解析dom樹
    result.domTime = fix(ptiming.domComplete - ptiming.domInteractive);
    // DOMready
    result.domReady = fix(ptiming.domContentLoadedEventEnd - ptiming.navigationStart)
    // ...
  }
  // 路由切換狀態(tài)
  if (state === 'navigation') {
    // ...
  }
  return result
}

資源相關(guān)指標(biāo)的數(shù)據(jù)獲取關(guān)鍵邏輯：

// 記錄
let performanceCursor: number = 0;
// 獲取當(dāng)前頁面資源列表
export const startPerformance = (task: TaskTypes) => {
  const { timeOrigin } = task.ctx;
  if (!window.performance || !window.performance.getEntries || !timeOrigin) {
    return;
  }
  // performanceEntries
  const performanceEntries = performance.getEntries();
  const pss = performanceEntries.slice(performanceCursor);
  // 處理 各種 performanceEntry 資源
  formatResourceEntries(task, pss);
  performanceCursor = Math.max(performanceEntries.length - 1, 0);
}
export const formatResourceEntries = (task: TaskTypes, entries: PerformanceEntryList) => {
  const { state, startTimestamp, timeOrigin } = task.ctx;
  const { metrics } = task
  entries.forEach(entry => {
    const startTime = entry.startTime;
    // console.log( timeOrigin, startTime, startTimestamp, timeOrigin + startTime < startTimestamp)
    if (state === 'navigation' && timeOrigin + startTime < startTimestamp) {
      return;
    }
    const baseStartTime = startTimestamp - timeOrigin;
    switch (entry.entryType) {
      case 'navigation':
        // 處理 bodysize 
        // ...
      case 'paint':
        // 處理 paint 指標(biāo) fcp fp
        // ...
      case 'resource':
        // 序列化各種資源, 如js/css/img/jsonp/ajax/fetch/iframe...
        calcResource(entry, result, baseStartTime);
    }
    // ...
}

業(yè)務(wù)指標(biāo)數(shù)據(jù)的獲取：

// 初始化基礎(chǔ)業(yè)務(wù)指標(biāo)
export const initBaseData = (task: TaskTypes) => {
  const { params = { backup: {} }, options = {} } = task;
  // ...
  Object.assign(params, {
    pagetype: options?.pagetype || pagetype,
    actiontype: options?.actiontype || actiontype,
    appid: options?.appid || appid,
    // and more ...
  });
  return task;
}

longTask 的記錄獲?。?/p>

function startLongTasks(): void {
  const entryHandler = (entries: PerformanceEntry[]): void => {
    for (const entry of entries) {
      const startTime = entry.startTime
      const duration = entry.duration;
      const endTime = startTime + duration;
      const longtask = {
        name: `longtask-${++n}`,
        startTime,
        endTime,
        duration
      }
      longTasks.push(longtask);
    }
  };
  if(PerformanceObserver?.supportedEntryTypes?.includes('longtask')) {
    // 注冊 longtask 異步任務(wù)
    observe('longtask', entryHandler);
  }
}

在實(shí)際項(xiàng)目統(tǒng)計(jì)時(shí)，發(fā)現(xiàn)一些性能指標(biāo)算法的適用性問題需要注意：

1. LCP 算法存在的問題。比如：觸發(fā)條件限制的問題，當(dāng)檢測到用戶輸入時(shí)候 FMP算法會停止計(jì)算，就導(dǎo)致某些場景觸發(fā)不了（比如主要內(nèi)容還沒顯示就點(diǎn)擊頁面）。白屏占位圖問題，頁面初始有較大的白屏占位圖時(shí) 即使后面被移除了，LCP 算法還會把它當(dāng)作主要內(nèi)容。
2. FMP 算法不適合某些特殊場景。比如：2/3 是金剛位圖片布局，最下面 1/3 區(qū)域有一個(gè)瀑布流，由于FMP算法計(jì)算規(guī)則會導(dǎo)致統(tǒng)計(jì)時(shí)間在瀑布流請求之后展現(xiàn)后，就導(dǎo)致直觀上的頁面首屏?xí)r間變大。

數(shù)據(jù)可以計(jì)算并獲取了，那么如何進(jìn)行友好的處理上報(bào)？

由于內(nèi)部埋點(diǎn)提下不支持回話形式的分段上報(bào)，那么就需要在前端提前準(zhǔn)備好所有需要需要上報(bào)的數(shù)據(jù)的處理，整體B端 SPA 項(xiàng)目性能數(shù)據(jù)處理的上報(bào)處理機(jī)制，以及同步任務(wù)數(shù)據(jù)、異步任務(wù)數(shù)據(jù)任務(wù)的處理流如下圖所示。

3. 上報(bào)數(shù)據(jù)的體積優(yōu)化

在進(jìn)行數(shù)據(jù)上報(bào)時(shí)，如果頁面的靜態(tài)資源加載 / ajax請求數(shù)量很多時(shí)，埋點(diǎn)上報(bào)請求接口的 body 會很大，導(dǎo)致請求耗時(shí)長而影響頁面本身的性能。因此針對 body 過大的問題，對一些資源的統(tǒng)計(jì)做了序列化處理。

比如：單條靜態(tài)資源的原始數(shù)據(jù)結(jié)構(gòu)為：

const entry:PerformanceResourceTiming = {
  "name": "https://xxx.zzz.com/yyy.css?v=5J1NDtbnnIr2Rc2SdhEMlMxD4l9Eydj88B31E7_NhS4",
  "entryType": "resource",
  "startTime": 1924.6000000238419,
  "duration": 1400.5999999642372,
  "initiatorType": "link",
  "fetchStart": 1924.6000000238419,
  "responseEnd": 3325.199999988079,
}

序列化之后，將各個(gè)關(guān)鍵數(shù)據(jù)合并成一個(gè)字符串，即：

// 將 entries 分類，并把單個(gè)entry 進(jìn)行字符串化后，再將所有 css entry 合并
const cssEntry:string = 'https://xxx.zzz.com/yyy.css|1924|1924|3325'

可以發(fā)現(xiàn)系列化精簡后將 255個(gè)字符優(yōu)化成了 42 個(gè)字符。

往往B端 SPA 項(xiàng)目靜態(tài)資源和請求多達(dá)幾十上百個(gè)，這樣序列化處理合并之后，能將埋點(diǎn)上報(bào)請求 body 體積減少數(shù)千個(gè)字節(jié)。當(dāng)然了，如果服務(wù)支持編解碼，還可以通過其他更優(yōu)的序列化方案進(jìn)行 body 體積壓縮。

4. 數(shù)據(jù)存儲與處理

在對數(shù)據(jù)進(jìn)行處理時(shí)，也遇到了一些問題。

每天上報(bào)的性能埋點(diǎn)數(shù)據(jù)存儲在哪里？

如何計(jì)算數(shù)據(jù)？如何擴(kuò)展數(shù)據(jù)？如何查詢數(shù)據(jù)？

二次計(jì)算后的數(shù)據(jù)量依舊非常大，該怎么辦？

• 原始性能數(shù)據(jù)通過SDK采集后，經(jīng)過數(shù)據(jù)倉庫的清洗，存儲在Hadoop中。雖然Hadoop可以存儲PB級別的數(shù)據(jù)，但查詢速度較慢，不適合實(shí)時(shí)性能分析查詢。為了解決這個(gè)問題，我們嘗試將清洗后的數(shù)據(jù)復(fù)制一份存儲在MySQL中，但隨著數(shù)據(jù)量的增加，MySQL方案出現(xiàn)了許多問題。考慮到實(shí)際場景的并發(fā)量不會太高，我們最終選擇將明細(xì)數(shù)據(jù)存儲在ClickHouse中。
• 雖然明細(xì)數(shù)據(jù)可以通過查詢ClickHouse獲取，但對于許多聚合計(jì)算得出的數(shù)據(jù)，如果仍然通過查詢并實(shí)時(shí)計(jì)算，效率并不理想。因此，在數(shù)據(jù)落庫后，我們通過定時(shí)任務(wù)預(yù)先計(jì)算一部分聚合數(shù)據(jù)，然后將其導(dǎo)入MySQL中。這種做法的好處在于，這部分預(yù)先計(jì)算好的數(shù)據(jù)可以進(jìn)行查詢，用戶體驗(yàn)更好，而且后續(xù)需要擴(kuò)展時(shí)，只需要對聚合數(shù)據(jù)進(jìn)行二次計(jì)算加工即可。目前，聚合數(shù)據(jù)使用了6個(gè)維度進(jìn)行分組計(jì)算，這些維度也可以用于組合查詢，方便后續(xù)擴(kuò)展。
• 盡管聚合數(shù)據(jù)已經(jīng)合并計(jì)算過，但由于多維度組合，數(shù)據(jù)量仍然非常龐大。隨著后續(xù)維度的擴(kuò)展，整體數(shù)據(jù)量呈指數(shù)級增長?？紤]到性能分析的周期性不會太長，我們決定只保留整體聚合數(shù)據(jù)7天，并進(jìn)行分表處理。如果數(shù)據(jù)量激增，我們會采取將數(shù)據(jù)轉(zhuǎn)入TiDB中，并按日期進(jìn)行分區(qū)存儲。

為了解決數(shù)據(jù)處理中的兩個(gè)核心問題，我們采用了這個(gè)完整的流程。在面對如此龐大的數(shù)據(jù)時(shí)，我們需要考慮它們存儲在何處。同時(shí)，我們也需要考慮如何查找和計(jì)算需要的指標(biāo)。這個(gè)流程可以幫助我們更好地處理數(shù)據(jù)，提高效率。

此外，這個(gè)流程還有一個(gè)重要的作用，那就是保證數(shù)據(jù)的準(zhǔn)確性和完整性。在數(shù)據(jù)處理過程中，我們需要遵循一定的規(guī)則和標(biāo)準(zhǔn)，以確保數(shù)據(jù)的可靠性。這樣才能讓我們在分析數(shù)據(jù)時(shí)得出正確的結(jié)論，更好的進(jìn)行針對性的優(yōu)化。

5. 性能查詢展示平臺

web平臺部分功能頁面展示如下:

歷史變化曲線

性能數(shù)據(jù)查詢

總結(jié)

在B端項(xiàng)目中，頁面性能統(tǒng)計(jì)是非常有必要的，因?yàn)榭梢詭椭覀兞私鈱?shí)際用戶的具體頁面的加載速度、用戶體驗(yàn)，以便了解當(dāng)前頁面的質(zhì)量，并且為優(yōu)化頁面性能提供方向，從而提高用戶滿意度。