建站
咨詢
售后
建站咨詢
新聞中心
背景
由于轉(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)上報體系的 PC 端項(xiàng)目網(wǎng)頁的性能統(tǒng)計平臺。
B 端性能統(tǒng)計面臨的問題
由于內(nèi)部性能埋點(diǎn)統(tǒng)計體系不支持分批/分段上報，每個 Router 都需要作為一個單獨(dú)的頁面進(jìn)行一次性的性能數(shù)據(jù)上報。在 B 端，一些新的指標(biāo)需要支持和特殊處理。因此，在數(shù)據(jù)采集統(tǒng)計方面，我們會遇到以下幾個問題。
- SPA Router 問題 轉(zhuǎn)轉(zhuǎn)內(nèi)部 C 端項(xiàng)目主要采用 hybrid 技術(shù)棧，因此不需要對 SPA 項(xiàng)目路由做特殊處理（因?yàn)槊看味奸_啟一個 webview，類似于多頁面應(yīng)用應(yīng)用場景）。但是，基于 React 技術(shù)棧的 B 端項(xiàng)目是 SPA 項(xiàng)目，為了方便統(tǒng)計每個 Router 頁面的性能數(shù)據(jù)，我們需要對每個 Router 頁面的加載進(jìn)行一些特殊處理。
- SPA 資源統(tǒng)計問題 現(xiàn)在的前端 SPA 項(xiàng)目一般都會通過異步加載頁面資源的方式，進(jìn)行頁面打包體積的優(yōu)化，以提升頁面首屏性能。因此，在進(jìn)行資源統(tǒng)計時，我們需要單獨(dú)對相應(yīng)的 Router 頁面的加載資源進(jìn)行統(tǒng)計處理。
- B 端指標(biāo)定義問題 轉(zhuǎn)轉(zhuǎn) B 端性能統(tǒng)計主要參考核心指標(biāo)：白屏、首屏、完全加載。頁面性能分?jǐn)?shù)評估也主要基于這三個指標(biāo)進(jìn)行加權(quán)計算。但是，在 Router 頁面加載時，我們會遇到核心性能指標(biāo)無法直接獲取的問題，因?yàn)?Router 切換并不會產(chǎn)生頁面的 load，而只是 div 的顯示隱藏。當(dāng)然了，還需要其他 B 端特有的業(yè)務(wù)標(biāo)識定義，這里不一一列舉。
主要內(nèi)容
1. 性能指標(biāo)定義
定義好哪些性能指標(biāo)需要上報，是做好一個完善的采集性能數(shù)據(jù)采集 sdk 的前提條件，經(jīng)過分析主要將指標(biāo)分為兩類：1. 純 H5 頁面性能指標(biāo) 2. 頁面相關(guān)業(yè)務(wù)性指標(biāo)。
- 純 H5 頁面性能指標(biāo)
- 性能核心指標(biāo)主要包括：白屏?xí)r間 、 首屏?xí)r間、 頁面完全加載時間，以及新增的用戶體驗(yàn)指標(biāo) LCP、 FID、 CLS 。
- 輔助性性能指標(biāo)包括：DNS 解析 、請求響應(yīng)時間、 DOM開始構(gòu)建時間、 頁面可交互時間、 DOM構(gòu)建完成時間、 網(wǎng)絡(luò)速度、 各類靜態(tài)資源耗時、 ajax請求耗時、 LongTask 等等。
以上提到的絕大部分指標(biāo)，可以通過瀏覽器提供的 PerformanceNavigationTiming PerformanceResourceTiming API 和 谷歌團(tuán)隊(duì)提供的 web-vitals 工具函數(shù)很方便的進(jìn)行獲取和計算。
- 業(yè)務(wù)性相關(guān)指標(biāo):
所謂業(yè)務(wù)性指標(biāo)，主要是作為查詢分析的一些要素，比如 我們想查詢某個業(yè)務(wù)線的某個項(xiàng)目的某個頁面在某個平臺下某個性能指標(biāo)的表現(xiàn)如何？那么就需要一些非頁面性能本身的業(yè)務(wù)要素指標(biāo)進(jìn)行定義和上報統(tǒng)計。
業(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 端作為一個必選項(xiàng)，但 B 端用戶絕大多數(shù)使用 chromium 內(nèi)核瀏覽器，所以大膽的將 web-vitals 納入采集指標(biāo)中
2. 指標(biāo)數(shù)據(jù)的獲取與上報
上面進(jìn)行了各種指標(biāo)的定義，那么如何高效有序的接入到轉(zhuǎn)轉(zhuǎn)埋點(diǎn)體系內(nèi)進(jìn)行上報統(tǒng)計呢？轉(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)行上報統(tǒng)計，方便在代碼層面更好的進(jìn)行結(jié)構(gòu)上的解耦，并且盡量做到性能計算統(tǒng)計相關(guān)程序不影響頁面本身的性能，在技術(shù)實(shí)現(xiàn)設(shè)計層我們把上面的指標(biāo)做了一些分類，比如 同步計算指標(biāo)（基礎(chǔ)業(yè)務(wù)同步指標(biāo)、基礎(chǔ)性能資源同步指標(biāo)）、異步計算指標(biāo)（性能異步指標(biāo)、后置異步指標(biāo)）等。具體如下圖所示。
技術(shù)層面指標(biāo)分類
下面詳細(xì)介紹一下一些關(guān)鍵邏輯是怎么處理的？各類性能指標(biāo)具體是怎么計算的？下面列出了部分指標(biāo)怎么獲取和計算的關(guān)鍵代碼。
SPA 項(xiàng)目的路由頁面的攔截關(guān)鍵邏輯：
const hackRouter = () => {
if (!window?.history?.pushState) {
return;
}
// 瀏覽器的歷史記錄發(fā)生變化時被觸發(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ù)的獲?。?/p>
// 初始化基礎(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 的記錄獲取：
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)計時，發(fā)現(xiàn)一些性能指標(biāo)算法的適用性問題需要注意：
- LCP 算法存在的問題。比如：觸發(fā)條件限制的問題，當(dāng)檢測到用戶輸入時候 FMP算法會停止計算，就導(dǎo)致某些場景觸發(fā)不了（比如主要內(nèi)容還沒顯示就點(diǎn)擊頁面）。白屏占位圖問題，頁面初始有較大的白屏占位圖時 即使后面被移除了，LCP 算法還會把它當(dāng)作主要內(nèi)容。
- FMP 算法不適合某些特殊場景。比如：2/3 是金剛位圖片布局，最下面 1/3 區(qū)域有一個瀑布流，由于FMP算法計算規(guī)則會導(dǎo)致統(tǒng)計時間在瀑布流請求之后展現(xiàn)后，就導(dǎo)致直觀上的頁面首屏?xí)r間變大。
數(shù)據(jù)可以計算并獲取了，那么如何進(jìn)行友好的處理上報？
由于內(nèi)部埋點(diǎn)提下不支持回話形式的分段上報，那么就需要在前端提前準(zhǔn)備好所有需要需要上報的數(shù)據(jù)的處理，整體B端 SPA 項(xiàng)目性能數(shù)據(jù)處理的上報處理機(jī)制，以及同步任務(wù)數(shù)據(jù)、異步任務(wù)數(shù)據(jù)任務(wù)的處理流如下圖所示。
3. 上報數(shù)據(jù)的體積優(yōu)化
在進(jìn)行數(shù)據(jù)上報時，如果頁面的靜態(tài)資源加載 / ajax請求數(shù)量很多時，埋點(diǎn)上報請求接口的 body 會很大，導(dǎo)致請求耗時長而影響頁面本身的性能。因此針對 body 過大的問題，對一些資源的統(tǒng)計做了序列化處理。
比如：單條靜態(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,
}序列化之后，將各個關(guān)鍵數(shù)據(jù)合并成一個字符串，即：
// 將 entries 分類，并把單個entry 進(jìn)行字符串化后，再將所有 css entry 合并
const cssEntry:string = 'https://xxx.zzz.com/yyy.css|1924|1924|3325'
可以發(fā)現(xiàn)系列化精簡后將 255個字符優(yōu)化成了 42 個字符。
往往B端 SPA 項(xiàng)目靜態(tài)資源和請求多達(dá)幾十上百個，這樣序列化處理合并之后，能將埋點(diǎn)上報請求 body 體積減少數(shù)千個字節(jié)。當(dāng)然了，如果服務(wù)支持編解碼，還可以通過其他更優(yōu)的序列化方案進(jìn)行 body 體積壓縮。
4. 數(shù)據(jù)存儲與處理
在對數(shù)據(jù)進(jìn)行處理時，也遇到了一些問題。
每天上報的性能埋點(diǎn)數(shù)據(jù)存儲在哪里？
如何計算數(shù)據(jù)？如何擴(kuò)展數(shù)據(jù)？如何查詢數(shù)據(jù)？
二次計算后的數(shù)據(jù)量依舊非常大，該怎么辦？
- 原始性能數(shù)據(jù)通過SDK采集后，經(jīng)過數(shù)據(jù)倉庫的清洗，存儲在Hadoop中。雖然Hadoop可以存儲PB級別的數(shù)據(jù)，但查詢速度較慢，不適合實(shí)時性能分析查詢。為了解決這個問題，我們嘗試將清洗后的數(shù)據(jù)復(fù)制一份存儲在MySQL中，但隨著數(shù)據(jù)量的增加，MySQL方案出現(xiàn)了許多問題?？紤]到實(shí)際場景的并發(fā)量不會太高，我們最終選擇將明細(xì)數(shù)據(jù)存儲在ClickHouse中。
- 雖然明細(xì)數(shù)據(jù)可以通過查詢ClickHouse獲取，但對于許多聚合計算得出的數(shù)據(jù)，如果仍然通過查詢并實(shí)時計算，效率并不理想。因此，在數(shù)據(jù)落庫后，我們通過定時任務(wù)預(yù)先計算一部分聚合數(shù)據(jù)，然后將其導(dǎo)入MySQL中。這種做法的好處在于，這部分預(yù)先計算好的數(shù)據(jù)可以進(jìn)行查詢，用戶體驗(yàn)更好，而且后續(xù)需要擴(kuò)展時，只需要對聚合數(shù)據(jù)進(jìn)行二次計算加工即可。目前，聚合數(shù)據(jù)使用了6個維度進(jìn)行分組計算，這些維度也可以用于組合查詢，方便后續(xù)擴(kuò)展。
- 盡管聚合數(shù)據(jù)已經(jīng)合并計算過，但由于多維度組合，數(shù)據(jù)量仍然非常龐大。隨著后續(xù)維度的擴(kuò)展，整體數(shù)據(jù)量呈指數(shù)級增長?？紤]到性能分析的周期性不會太長，我們決定只保留整體聚合數(shù)據(jù)7天，并進(jìn)行分表處理。如果數(shù)據(jù)量激增，我們會采取將數(shù)據(jù)轉(zhuǎn)入TiDB中，并按日期進(jìn)行分區(qū)存儲。
為了解決數(shù)據(jù)處理中的兩個核心問題，我們采用了這個完整的流程。在面對如此龐大的數(shù)據(jù)時，我們需要考慮它們存儲在何處。同時，我們也需要考慮如何查找和計算需要的指標(biāo)。這個流程可以幫助我們更好地處理數(shù)據(jù)，提高效率。
此外，這個流程還有一個重要的作用，那就是保證數(shù)據(jù)的準(zhǔn)確性和完整性。在數(shù)據(jù)處理過程中，我們需要遵循一定的規(guī)則和標(biāo)準(zhǔn)，以確保數(shù)據(jù)的可靠性。這樣才能讓我們在分析數(shù)據(jù)時得出正確的結(jié)論，更好的進(jìn)行針對性的優(yōu)化。
5. 性能查詢展示平臺
web平臺部分功能頁面展示如下:
歷史變化曲線
性能數(shù)據(jù)查詢
總結(jié)
在B端項(xiàng)目中，頁面性能統(tǒng)計是非常有必要的，因?yàn)榭梢詭椭覀兞私鈱?shí)際用戶的具體頁面的加載速度、用戶體驗(yàn)，以便了解當(dāng)前頁面的質(zhì)量，并且為優(yōu)化頁面性能提供方向，從而提高用戶滿意度。
網(wǎng)站欄目：轉(zhuǎn)轉(zhuǎn)B端項(xiàng)目頁面性能統(tǒng)計實(shí)踐
網(wǎng)頁URL：http://www.5511xx.com/article/djjsdss.html
