背景

字節(jié)各類業(yè)務(wù)擁有眾多用戶群，作為字節(jié)前端性能監(jiān)控 SDK，自身若存在性能問題，則會影響到數(shù)以億計的真實用戶的體驗，所以此類 SDK 自身的性能在設(shè)計之初，就必須達到一個非常極致的水準(zhǔn)。

與此同時，隨著業(yè)務(wù)不斷迭代，功能變得越來越多，對監(jiān)控的需求也會變得越來越多。例如，今天 A 業(yè)務(wù)更新了架構(gòu)，想要自定義性能指標(biāo)的獲取規(guī)則，明天 B 業(yè)務(wù)接入了微前端框架，需要監(jiān)控子應(yīng)用的性能。在解決這些業(yè)務(wù)需求的同時，我們會不斷加入額外的判斷邏輯、配置項。同時由于用戶的電腦性能、瀏覽器環(huán)境的不同，我們又要解決各種兼容性問題，加入 polyfill 等代碼，不可避免地造成 SDK 體積膨脹，性能劣化。那么我們是如何在需求和功能不斷迭代的情況下，持續(xù)追蹤和優(yōu)化 SDK 的體積和性能的呢？

SDK 體積優(yōu)化

通常而言，體積的優(yōu)化是最容易拿到收益的一項。

由于監(jiān)控 SDK 通常作為第一個腳本被加載到頁面中，體積的膨脹不僅會增加用戶的下載時間，還會增加瀏覽器解析腳本的時間。對于體積優(yōu)化，我們可以從宏觀和微觀兩個角度去實現(xiàn)。

微觀上，我們會去盡可能去精簡所有的表達，剝離冗余重復(fù)代碼，同時盡可能減少以下寫法的出現(xiàn)：

1.過多的 class 和過長的屬性方法名

Class 的定義會被轉(zhuǎn)換成 function 聲明 + prototype 賦值，以及常用代碼壓縮工具無法對 object 屬性名壓縮，過多的面向?qū)ο髮懛〞尵幾g后的 js 代碼體積膨脹得非?？?。例如下列代碼：

class ClassWithLongName {
    methodWithALongLongName() {}
}

經(jīng)過 ts 轉(zhuǎn)換后會變成：

var ClassWithLongName = /** @class */ (function () {
    function ClassWithLongName() {
    }
    ClassWithLongName.prototype.methodWithALongLongName = function () { };
    return ClassWithLongName;
}());

壓縮后代碼為：

var ClassWithLongName=function(){function n(){}return n.prototype.methodWithALongLongName=function(){},n}();

可以看到以上長命名都無法被壓縮。

如果使用函數(shù)式編程來代替面向?qū)ο缶幊?，能夠很好的避免代碼無法被壓縮的情況：

function functionWithLongName() {
  return function MethodWithALongLongName(){}
}

經(jīng)過壓縮后變成：

function n(){return function(){}}

相較于 class 的版本，壓縮后的代碼減小了50%以上。

2、內(nèi)部函數(shù)傳參使用數(shù)組代替對象

原理同上，對象中的字段名通常不會被代碼壓縮工具壓縮。同時合理使用 TS named tuple 類型可以保證代碼可維護性。

function report(event, {optionA, optionB, optionC, optionD}: ObjectType){
}

改為：

function report(event, [optionA, optionB, optionC, optionD]: NamedTupleType){
}

3、在不需要判斷 nullable 時，盡可能避免?. ?? ??= 等操作符的出現(xiàn)。同理，盡可能避免一些例如 spread 操作符、generator 等新語法，這些語法在編譯成 es5 后通常會引入額外的 polyfill。

TS 會將這些操作符轉(zhuǎn)換成非常長的代碼，例如 a?.b會被轉(zhuǎn)換成：

a === null || a === void 0 ? void 0 : a.b

過多的 nullish 操作符也是代碼體積增加的一個原因。

當(dāng)然，以上只列舉了部分體積優(yōu)化措施，還有更多優(yōu)化方法要結(jié)合具體代碼而議。對于我們的前端監(jiān)控 SDK，為了性能和體積是可以犧牲一些開發(fā)體驗的，并且由于使用 TS 類型系統(tǒng)，并不會對代碼維護增加很多負擔(dān)。

從宏觀上，我們應(yīng)該思考如何減少 SDK 所依賴的模塊，減少產(chǎn)物包含的內(nèi)容，增加產(chǎn)物的“信噪比”，有以下幾個方式：

1.拆分文件

我們可以分離出 SDK 中不是必須提前執(zhí)行的邏輯，拆分成異步加載的文件，僅將必須提前執(zhí)行的邏輯加入初始腳本。同時將不同功能拆分成不同文件，業(yè)務(wù)按需加載，這樣可以最大程度減少對首屏加載時間的影響。

2.盡可能避免 polyfill 的使用

polyfill 會顯著增加產(chǎn)物體積，我們盡可能不使用存在兼容性的方法。甚至在不需要兼容低端瀏覽器環(huán)境時，我們可以不使用 polyfill。

3.減少重復(fù)的常量字符串的出現(xiàn)次數(shù)

對于多次重復(fù)出現(xiàn)的常量字符串，提取成公共變量。例如

a.addEventListener('load', cb)
b.addEventListener('load', cb)
c.addEventListener('load', cb)

我們可以將 addEventListener?和 load 提取公共變量：

let ADD_EVENT_LISTENER = 'addEventLister'
let LOAD = 'load'
a[ADD_EVENT_LISTENER](LOAD, cb)
b[ADD_EVENT_LISTENER](LOAD, cb)
c[ADD_EVENT_LISTENER](LOAD, cb)

此段代碼壓縮后會變成：

let d="addEventLister",e="load";a[d](e,cb),b[d](e,cb),c[d](e,cb);

我們還可以使用 TSTransformer 或者 babel plugin 來幫我們自動地完成上述過程。

值得注意的是，這個方法在 web 端并不能取得很好的收益，因為瀏覽器在傳輸數(shù)據(jù)時會做 gzip 壓縮，已經(jīng)將重復(fù)信息用最高效的算法壓縮了，我們做的并不會比 gzip 更好。但是在需要嵌入移動端 app 的監(jiān)控 SDK 來說，這一做法能減少約 10 ~ 15% 產(chǎn)物體積。

除了體積優(yōu)化以外，隨著需求不斷增加，功能不斷完善，不可避免的會影響到 SDK 的性能。接下來，我們介紹如何測量并優(yōu)化 SDK 的性能。

使用工具進行性能衡量

通常來說，監(jiān)控類 SDK 最有可能影響性能的地方為：

1. 監(jiān)控初始化時執(zhí)行各類監(jiān)聽的過程。
2. 監(jiān)控事件上報請求對業(yè)務(wù)的影響。
3. SDK 維護數(shù)據(jù)緩存時的內(nèi)存使用情況。

接下來，我們著重從以上幾個維度來衡量并優(yōu)化 SDK 的性能。

性能衡量過程

使用 Benchmark 性能衡量工具的目的便是為了知道 SDK 運行過程中每一個函數(shù)執(zhí)行的耗時，給業(yè)務(wù)帶來多大的影響，是否會引起 longtask。由于我們的監(jiān)控 SDK 包含了性能、請求、資源等各類前端監(jiān)控能力，這些功能的實現(xiàn)依賴對頁面各類事件的監(jiān)聽、性能指標(biāo)的獲取、請求對象的包裝。除此之外，SDK還提供給用戶（開發(fā)者）調(diào)用的方法，例如配置頁面信息、自定義埋點、更改監(jiān)控行為等能力。根據(jù) SDK 以上行為和能力，我們將測試分為兩個模塊：

1. 接入 SDK 后自動運行的各類監(jiān)控，這些行為大部分會在頁面加載之初執(zhí)行，若此部分性能劣化，會嚴(yán)重影響到所有前端業(yè)務(wù)用戶的首屏加載。
2. 用戶端（開發(fā)者）調(diào)用的方法，我們會將此類方法包裝成 client 對象以 npm 包的形式給開發(fā)者調(diào)用，這部分方法的執(zhí)行由用戶控制，可能存在頻繁調(diào)用的情況，因此也應(yīng)避免耗時過長的調(diào)用出現(xiàn)。

在過往文章前端監(jiān)控系列1｜ 字節(jié)的前端監(jiān)控 SDK 是怎樣設(shè)計的中我們講到，我們的 SDK 在設(shè)計時已經(jīng)做到的盡可能的解耦，各個模塊各司其職，這一特點非常便于我們針對各個模塊方法進行單獨的性能衡量。

下面我們以使用 benny (https://github.com/caderek/benny) 這一開源工具為例，展示一段方便理解 benchmark 過程的偽代碼，僅作參考：

benny 是一個非常簡單易用的 benchmark 工具，通過 suite? 方法創(chuàng)建測試用例組合，通過add?方法添加需要測試的函數(shù)，cycle?方法用于多次循環(huán)執(zhí)行測試用例，complete用于添加測試完成之后的回調(diào)函數(shù)。更多詳細的使用說明可以查閱官方文檔。

const { suite, add, cycle, complete, save } = require('benny')
// 衡量 SDK 各類監(jiān)控初始化運行性能
suite(
  'collectors setup',
  add('route', () => route(context)),
  add('exception', () => exception(context)),
  add('ajax', () => ajax(context)),
  add('FCP', getFCP),
  add('LCP', getLCP),
  add('longtask', getLongtask),
  cycle(),
  complete(),
)

// 衡量 Client 實例方法耗時
suite(
  'npm client',
  add('set config', () => client.config({pid})),
  add('set context', () => client.context.set({ something })),
  add('send custom pv', () => client.sendPageView(pid)),
  add('send custom event', () => client.sendCustom(ev)),
  // ... 
  cycle(),
  complete(),
)

通常這類 benchmark 工具都是在 Node 上執(zhí)行的，但是我們的 SDK 是個前端監(jiān)控 SDK，依賴了非常多的瀏覽器環(huán)境對象，我們幾乎不可能在 Node 環(huán)境去創(chuàng)造或模擬這些對象，我們有沒有辦法在瀏覽器里去運行這段腳本，做性能自動化測試呢？

利用 Puppeteer 在瀏覽器環(huán)境中執(zhí)行 Benchmark

由于我們的前端監(jiān)控依賴瀏覽器環(huán)境，我們可以將上述 benchmark 測試代碼打包成 commonjs 之后放入 headless chrome 瀏覽器中執(zhí)行，并通過 puppeteer 收集執(zhí)行結(jié)果。

Puppeteer 是一個 Node 模塊，提供了通過 Devtool Protocol 控制 Chrome 或者 Chromium 的能力。Puppeteer 默認運行 Chrome 的無頭版本，也可以通過設(shè)置運行 Chrome 用戶界面版。

下面是一段方便理解操作 puppeteer 過程的偽代碼，僅作參考，實際情況較為復(fù)雜，需要等待未完成的異步請求等：

const browser = await puppeteer.launch()
const page = await browser.newPage()
const cdp = await page.target().createCDPSession()

// 用于 benchmark 腳本和 puppeteer 之間的通信，用以收集結(jié)果
await page.evaluate(() => (window.benchmarks = []))
// 將 pushResult 方法暴露給瀏覽器，來將結(jié)果收集到 node 端
await page.exposeFunction(
    'pushResult',
    (result: any) => benchmark.results.push(result)
)

await cdp.send('Profiler.enable')
await cdp.send('Profiler.start')

// 開始執(zhí)行 benchmark
await page.addScriptTag({
  content: file.toString(),
})

await Promise.race([timeout, allBenchmarksDone()])

// profile 可用于繪制火焰圖
const { profile } = await cdp.send('Profiler.stop')
await page.close()

通過運行以上腳本，我們便可以在無頭瀏覽器中運行我們的性能測試腳本，在測試腳本產(chǎn)出結(jié)果后添加調(diào)用 pushResult 方法來收集測試結(jié)果。

在實際的 benchmark 測試中，我們發(fā)現(xiàn)開啟性能監(jiān)聽（即運行各個性能監(jiān)控的 PerformanceObserver.observe 方法）最大耗時達到了21ms，雖然看上去并不久，但若和其他監(jiān)聽同時執(zhí)行，加上引入業(yè)務(wù)代碼的復(fù)雜性和移動端更弱的 CPU 性能，極有可能成為給業(yè)務(wù)帶來 longtask 的罪魁禍?zhǔn)?。性能監(jiān)控性能成為了瓶頸。

接下來，我們將性能監(jiān)聽一個個拆分，用同樣的方式單獨測試每一個性能監(jiān)聽的耗時。在實際的 benchmark 結(jié)果中，我們發(fā)現(xiàn) fp、fcp、lcp、cls 監(jiān)控耗時最大，加在一起超過了10ms，占了一半以上，是我們之后需要重點優(yōu)化的地方。

除此之外利用 puppeteer 的能力，我們不僅可以得到 benchmark 的結(jié)果，還可以獲取到整個 benchmark 過程的 profile 數(shù)據(jù)，利用 speedscope (https://github.com/jlfwong/speedscope/blob/main/README-zh_CN.md) 繪制出函數(shù)執(zhí)行過程中的火焰圖：

繪制火焰圖的具體實現(xiàn)不在本文討論范圍內(nèi)，感興趣的同學(xué)可以參考 speedscope 官方文檔

此處顯示的時間為該用例執(zhí)行總耗時（單次耗時*次數(shù)）

如何衡量異步任務(wù)性能？

Benny 的 api 是支持異步測試用例的，測量的是每個異步函數(shù)從開始執(zhí)行到 resolve 的時間。但通常這并不是我們想要的衡量的數(shù)據(jù)，因為異步任務(wù)的執(zhí)行過程中并不是一直占據(jù)著主線程。對于一些異步的定時任務(wù)（例如 SDK 的崩潰檢測、卡頓檢測、白屏檢測），將他們拆解為一系列可測的同步任務(wù)能更直觀的展示各個階段的性能耗時。

例如我們 SDK 的前端白屏檢測，由一個 mutationObserver 和觸發(fā)白屏檢測的函數(shù)組成。我們可以單獨對 mutationObserver 的回調(diào)和觸發(fā)函數(shù)做性能衡量。

這兩個方法已沒有很好的優(yōu)化方式了。但是根據(jù) benchmark 結(jié)果并結(jié)合源碼可以發(fā)現(xiàn)，性能監(jiān)控所有指標(biāo)項的開啟均為同步執(zhí)行，每一項指標(biāo)都會對頁面做事件監(jiān)聽或者 PerformanceObserver 監(jiān)聽，且這些原生監(jiān)聽耗時都在毫秒級。于是我們對性能做了如下優(yōu)化：

1. 性能監(jiān)控邏輯分片運行，將各項性能指標(biāo)的監(jiān)聽同步拆為異步，用 requestIdleCallback (https://developer.mozilla.org/zh-CN/docs/Web/API/Window/requestIdleCallback) 做調(diào)度并區(qū)分優(yōu)先級。
2. 多個性能指標(biāo)監(jiān)聽同一事件的公用監(jiān)聽器，例如 CLS 和 LCP 都需要監(jiān)聽 onBFCacheRestore，讓他們只做一次 addEventListener。
3. 可以延遲執(zhí)行的方法延遲執(zhí)行，例如在高版本的 Chrome 中 PerformanceObserver 是有 buffer (https://www.w3.org/TR/performance-timeline-2/#dom-performanceobserverinit-buffered) 的，可以直接獲取到調(diào)用之前的性能指標(biāo)，這些方法調(diào)用就可以等待頁面完全加載完成之后執(zhí)行，從而盡可能減少對業(yè)務(wù)頁面首屏影響。

通過 Perfsee 的 Lab 結(jié)果分析性能問題

以上的 benchmark 流程得到的結(jié)果畢竟是一種理想化、單純的方法調(diào)用的性能情況，然而在實際瀏覽器環(huán)境中我們前端監(jiān)控 SDK 對性能影響有多大呢，對于這一類頁面初始化即加載的 SDK 可以通過 Perfsee (https://perfsee.com/) 的 Lab 功能進行性能衡量。

Perfsee 是一個針對前端 web 應(yīng)用在整個研發(fā)流程中的性能分析平臺。提供性能分析報告、產(chǎn)物分析報告、源碼分析、競品分析等模塊，定位與梳理性能問題，提供專業(yè)的優(yōu)化方案來漸進地優(yōu)化產(chǎn)品性能。

Lab 模塊性能分析的依據(jù)是，使用 headless 瀏覽器運行用戶指定的頁面，通過運行時數(shù)據(jù)的收集，分析并產(chǎn)出關(guān)鍵性能指標(biāo)分數(shù)、網(wǎng)絡(luò)請求信息、主線程 JS/渲染/Longtask 信息供業(yè)務(wù)方參考優(yōu)化。具體使用說明請查看 perfsee.com (https://perfsee.com/docs/cn/lab/get-started)

注意，本文所展示 Perfsee 功能示例為早期版本，并不與開源版本功能和界面完全一致。

準(zhǔn)備基準(zhǔn)頁面作為對照組

我們的目的是衡量 SDK 對業(yè)務(wù)性能造成的影響，便需要找到一個基準(zhǔn)頁面作為對比。此處以 React Server Component Demo (https://github.com/reactjs/server-components-demo) 為例作為基準(zhǔn)頁面。該應(yīng)用有以下幾個特點：

1. 容易搭建，一個命令就能跑起來。
2. 自身邏輯簡單，性能好，SDK 所造成的影響容易被放大觀察。
3. SPA 應(yīng)用，含有異步加載的邏輯，更容易探測到監(jiān)控 SDK 對頁面 FCP、LCP 等指標(biāo)影響。
4. 無外部網(wǎng)絡(luò)請求，頁面結(jié)果穩(wěn)定不易波動。

我們修改一下應(yīng)用的邏輯，能夠通過 url 參數(shù)注入監(jiān)控 sdk 腳本，把它部署在服務(wù)器上。接著，我們在 perfsee 平臺上配置好基準(zhǔn)頁面和注入 SDK 的頁面這兩個 page，并觸發(fā)一次性能掃描。

查看 Lab 性能報告

我們將沒有注入 SDK 的頁面作為空白組 (empty)，注入了 SDK 的頁面作為實驗組 (with-sdk)。

首先我們需要配置好空白組和實驗組的 pages 以及 profile，觸發(fā)一次 snapshot 之后，我們得到了多份報告，我們可以點擊 compare 將空白組和實驗組的數(shù)據(jù)進行比對。

在實際的 lab 性能掃描結(jié)果中，我們可以看到兩個頁面所有性能指標(biāo)的對比。我們發(fā)現(xiàn) sdk 的注入在 mobile profile（4倍降頻） 下還是給業(yè)務(wù)帶來了 fcp 70ms、lcp 90ms、load 200ms 的劣化。

同時我們還可以觀察到注入了 sdk 之后，fmp 和 lcp 之前的請求僅多了 1 個，這是符合預(yù)期的。不過這仍是我們保持觀察的指標(biāo)之一，因為在一些中低端的環(huán)境中，頁面加載完成之前每發(fā)出一個請求就可能讓業(yè)務(wù)更高優(yōu)先級的請求被延后，從而引起頁面性能指標(biāo)的下降。

切換到 Breakdown Tab，我們還可以看到頁面首屏?xí)r間線。我們需要重點關(guān)注幾個關(guān)鍵指標(biāo)（load、fcp、lcp）之前的線程占用情況，hover 在 load 之前這一黃色色塊上，我們發(fā)現(xiàn) sdk 在 load 之前執(zhí)行了 30ms，成為了拖慢了業(yè)務(wù)指標(biāo)的原因之一。

此處截圖省略了一些內(nèi)部信息，一般情況下，如果需要更多信息可以借助 Source 模塊來找到引起主線程密集計算的代碼位置。

在這個例子中，這個調(diào)用未觸發(fā) longtask，并且我們很容易發(fā)現(xiàn)這就是 SDK 初始化的邏輯，也是接下來需要優(yōu)化的地方。

問題分析與性能優(yōu)化

通過上述 benchmark 工具和 perfsee lab 性能分析結(jié)果，我們可以看出 SDK 初始化邏輯以及大量的事件監(jiān)聽確實對業(yè)務(wù)性能造成了一定影響。

例如上文火焰圖中所示每一個 onBFCacheRestore 都占用了超過 15ms 的時間，我們在源碼里搜索這個函數(shù)，此部分偽代碼如下：

const onBFCacheRestore = (cb) => {
    addEventListener('pageshow', (e) => {
        if (e.persisted) cb(e)
    }, true)
}

BFCache (https://web.dev/bfcache/) 即 back-forward cache，可稱為“往返緩存”，可以在用戶使用瀏覽器的“后退”和“前進”按鈕時加快頁面的轉(zhuǎn)換速度。這個緩存不僅保存頁面數(shù)據(jù)，還保存了 DOM 和 JS 的狀態(tài)，實際上是將整個頁面都保存在內(nèi)存里。如果頁面位于 BFCache 中，那么再次打開該頁面就不會觸發(fā) onload 事件。

可以看到，耗時主要由 onBFCacheRestore 和 onHidden 兩個方法中的原生 addEventListener 造成。這些監(jiān)聽本身都是在毫秒級的，回調(diào)函數(shù)也沒有什么優(yōu)化空間，從實際場景考慮，這兩處回調(diào)是為了監(jiān)聽用戶頁面前進和返回的，并非優(yōu)先級最高的任務(wù)。

我們可以從以下幾個方面降低對業(yè)務(wù)造成的影響：

1. 監(jiān)控任務(wù)切片運行，區(qū)分優(yōu)先級

對于監(jiān)控 SDK 而言，除了必要的監(jiān)聽以及事件預(yù)收集等任務(wù)，其他任何任務(wù)不應(yīng)該阻礙到業(yè)務(wù)代碼的執(zhí)行。對于字節(jié)前端監(jiān)控需求而言，異常和請求監(jiān)聽為必須前置執(zhí)行的任務(wù)，其他所有事件監(jiān)聽可以拆分為單獨的任務(wù)，所有的采樣、數(shù)據(jù)運算、上報請求等數(shù)據(jù)后處理邏輯只在空閑時執(zhí)行，通過 requestIdleCallback 調(diào)用。

2. 減少重復(fù)監(jiān)聽次數(shù)

多個性能指標(biāo)監(jiān)聽同一事件的公用監(jiān)聽器，例如 CLS 和 LCP 這兩個指標(biāo)都需要監(jiān)聽 onBFCacheRestore，讓他們只做一次 addEventListener。

3. 請求數(shù)量的優(yōu)化

我們 SDK 的腳本是由一個必須最先執(zhí)行的主腳本（包含預(yù)收集、請求hook、錯誤監(jiān)聽等邏輯）和多個通過不同配置開啟的異步插件腳本（性能、資源、白屏等）組成，主腳本的請求無法省略，而插件腳本可以通過接入 cdn combo 服務(wù)或自行搭建 combo 服務(wù)將多個請求合并成一個。

• 對于事件上報請求，我們在內(nèi)部維護一個緩存，只有當(dāng)間隔達到一定時間或者累計一定數(shù)量之后才會統(tǒng)一上報。在這個場景中，我們又需要考慮兩個問題：

• 瀏覽器對請求并發(fā)量有限制，所以存在網(wǎng)絡(luò)資源競爭的可能性
• 瀏覽器在頁面卸載時會忽略異步ajax請求，而同步 ajax 通常在現(xiàn)代瀏覽器中已被禁用

我們可以通過使用 navigator.sendBeacon 方法解決上述問題。

這個方法主要用于滿足統(tǒng)計和診斷代碼的需要，這些代碼通常嘗試在卸載（unload）文檔之前向 Web 服務(wù)器發(fā)送數(shù)據(jù)。過早的發(fā)送數(shù)據(jù)可能導(dǎo)致錯過收集數(shù)據(jù)的機會。然而，對于開發(fā)者來說保證在文檔卸載期間發(fā)送數(shù)據(jù)一直是一個困難。因為用戶代理通常會忽略在 unload (en-US)? 事件處理器中產(chǎn)生的異步 XMLHttpRequest

經(jīng)過以上優(yōu)化后，我們注入優(yōu)化過后的 SDK 再次跑分。

優(yōu)化后的 SDK 對業(yè)務(wù) FCP、LCP、LOAD 等性能的影響已經(jīng)降到了最低，已經(jīng)達到了非常高的性能標(biāo)準(zhǔn)。