背景
位元組各類業務擁有衆多使用者群，作為位元組前端性能監控 SDK，自身若存在性能問題，則會影響到數以億計的真實使用者的體驗。是以此類 SDK 自身的性能在設計之初，就必須達到一個非常極緻的水準。
與此同時，随着業務不斷疊代，功能變得越來越多，對監控的需求也會變得越來越多。例如，今天 A 業務更新了架構，想要自定義性能名額的擷取規則，明天 B 業務接入了微前端架構，需要監控子應用的性能。在解決這些業務需求的同時，我們會不斷加入額外的判斷邏輯、配置項。同時由于使用者的電腦性能、浏覽器環境的不同，我們又要解決各種相容性問題，加入 polyfill 等代碼，不可避免地造成 SDK 體積膨脹，性能劣化。那麼我們是如何在需求和功能不斷疊代的情況下，持續追蹤和優化 SDK 的體積和性能的呢？
SDK 體積優化
通常而言，體積的優化是最容易拿到收益的一項。
由于監控 SDK 通常作為第一個腳本被加載到頁面中，體積的膨脹不僅會增加使用者的下載下傳時間，還會增加浏覽器解析腳本的時間。對于體積優化，我們可以從宏觀和微觀兩個角度去實作。
微觀上，我們會去盡可能去精簡所有的表達，剝離備援重複代碼，同時盡可能減少以下寫法的出現：
- 過多的 class 和過長的屬性方法名
Class 的定義會被轉換成 function 聲明 + prototype 指派，以及常用代碼壓縮工具無法對 object 屬性名壓縮，過多的面向對象寫法會讓編譯後的 js 代碼體積膨脹得非常快。例如下列代碼
class ClassWithLongName {
methodWithALongLongName() {}
}
經過 ts 轉換後會變成
var ClassWithLongName = /** @class */ (function () {
function ClassWithLongName() {
}
ClassWithLongName.prototype.methodWithALongLongName = function () { };
return ClassWithLongName;
}());
壓縮後代碼為
var ClassWithLongName=function(){function n(){}return n.prototype.methodWithALongLongName=function(){},n}();
可以看到以上長命名都無法被壓縮
如果使用函數式程式設計來代替面向對象程式設計，能夠很好的避免代碼無法被壓縮的情況：
function functionWithLongName() {
return function MethodWithALongLongName(){}
}
經過壓縮後變成
function n(){return function(){}}
相較于 class 的版本，壓縮後的代碼減小了50%以上。
- 内部函數傳參使用數組代替對象
原理同上，對象中的字段名通常不會被代碼壓縮工具壓縮。同時合理使用 TS named tuple 類型可以保證代碼可維護性。
function report(event, {optionA, optionB, optionC, optionD}: ObjectType){
}
改為
function report(event, [optionA, optionB, optionC, optionD]: NamedTupleType){
}
- 在不需要判斷 nullable 時，盡可能避免
?.
??
??=
a?.b
a === null || a === void 0 ? void 0 : a.b
過多的 nullish 操作符也是代碼體積增加的一個原因。
當然，以上隻列舉了部分體積優化措施，還有更多優化方法要結合具體代碼而議。對于我們的前端監控 SDK，為了性能和體積是可以犧牲一些開發體驗的，并且由于使用 TS 類型系統，并不會對代碼維護增加很多負擔。
從宏觀上，我們應該思考如何減少 SDK 所依賴的子產品，減少産物包含的内容，增加産物的“信噪比”，有以下幾個方式：
- 拆分檔案
我們可以分離出 SDK 中不是必須提前執行的邏輯，拆分成異步加載的檔案，僅将必須提前執行的邏輯加入初始腳本。同時将不同功能拆分成不同檔案，業務按需加載，這樣可以最大程度減少對首屏加載時間的影響。
- 盡可能避免 polyfill 的使用
polyfill 會顯著增加産物體積，我們盡可能不使用存在相容性的方法。甚至在不需要相容低端浏覽器環境時，我們可以不使用 polyfill。
- 減少重複的常量字元串的出現次數
對于多次重複出現的常量字元串，提取成公共變量。例如
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 端并不能取得很好的收益，因為浏覽器在傳輸資料時會做 gzip 壓縮，已經将重複資訊用最高效的算法壓縮了，我們做的并不會比 gzip 更好。但是在需要嵌入移動端 app 的監控 SDK 來說，這一做法能減少約 10 ~ 15% 産物體積。
除了體積優化以外，随着需求不斷增加，功能不斷完善，不可避免的會影響到 SDK 的性能。接下來，我們介紹如何測量并優化 SDK 的性能。
使用工具進行性能衡量
通常來說，監控類 SDK 最有可能影響性能的地方為：
- 監控初始化時執行各類監聽的過程
- 監控事件上報請求對業務的影響
- SDK 維護資料緩存時的記憶體使用情況
接下來，我們着重從以上幾個次元來衡量并優化 SDK 的性能。
性能衡量過程
使用 Benchmark 性能衡量工具的目的便是為了知道 SDK 運作過程中每一個函數執行的耗時，給業務帶來多大的影響，是否會引起 longtask。由于我們的監控 SDK 包含了性能、請求、資源等各類前端監控能力，這些功能的實作依賴對頁面各類事件的監聽、性能名額的擷取、請求對象的包裝。除此之外，SDK還提供給使用者（開發者）調用的方法，例如配置頁面資訊、自定義埋點、更改監控行為等能力。根據 SDK 以上行為和能力，我們将測試分為兩個子產品：
- 接入 SDK 後自動運作的各類監控，這些行為大部分會在頁面加載之初執行，若此部分性能劣化，會嚴重影響到所有前端業務使用者的首屏加載。
- 使用者端（開發者）調用的方法，我們會将此類方法包裝成 client 對象以 npm 包的形式給開發者調用，這部分方法的執行由使用者控制，可能存在頻繁調用的情況，是以也應避免耗時過長的調用出現。
在前一篇文章 前端監控系列1｜ 位元組的前端監控SDK是怎樣設計的 中我們講到，我們的 SDK 在設計時已經做到的盡可能的解耦，各個子產品各司其職，這一特點非常便于我們針對各個子產品方法進行單獨的性能衡量。
下面我們以使用 benny 這一開源工具為例，展示一段友善了解 benchmark 過程的僞代碼，僅作參考：
💡 benny 是一個非常簡單易用的 benchmark 工具，通過方法建立測試用例組合，通過suite
方法添加需要測試的函數，add
方法用于多次循環執行測試用例，cycle
用于添加測試完成之後的回調函數。更多詳細的使用說明可以查閱官方文檔。complete
const { suite, add, cycle, complete, save } = require('benny')
// 衡量 SDK 各類監控初始化運作性能
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 上執行的，但是我們的 SDK 是個前端監控 SDK，依賴了非常多的浏覽器環境對象，我們幾乎不可能在 Node 環境去創造或模拟這些對象，我們有沒有辦法在浏覽器裡去運作這段腳本，做性能自動化測試呢？
利用 Puppeteer 在浏覽器環境中執行 Benchmark
由于我們的前端監控依賴浏覽器環境，我們可以将上述 benchmark 測試代碼打包成 commonjs 之後放入 headless chrome 浏覽器中執行，并通過 puppeteer 收集執行結果。
Puppeteer 是一個 Node 子產品，提供了通過 Devtool Protocol 控制 Chrome 或者 Chromium 的能力。Puppeteer 預設運作 Chrome 的無頭版本，也可以通過設定運作 Chrome 使用者界面版。
下面是一段友善了解操作 puppeteer 過程的僞代碼，僅作參考，實際情況較為複雜，需要等待未完成的異步請求等：
const browser = await puppeteer.launch()
const page = await browser.newPage()
const cdp = await page.target().createCDPSession()
// 用于 benchmark 腳本和 puppeteer 之間的通信，用以收集結果
await page.evaluate(() => (window.benchmarks = []))
// 将 pushResult 方法暴露給浏覽器，來将結果收集到 node 端
await page.exposeFunction(
'pushResult',
(result: any) => benchmark.results.push(result)
)
await cdp.send('Profiler.enable')
await cdp.send('Profiler.start')
// 開始執行 benchmark
await page.addScriptTag({
content: file.toString(),
})
await Promise.race([timeout, allBenchmarksDone()])
// profile 可用于繪制火焰圖
const { profile } = await cdp.send('Profiler.stop')
await page.close()
通過運作以上腳本，我們便可以在無頭浏覽器中運作我們的性能測試腳本，在測試腳本産出結果後添加調用 pushResult 方法來收集測試結果。
在實際的 benchmark 測試中，我們發現開啟性能監聽（即運作各個性能監控的 PerformanceObserver.observe 方法）最大耗時達到了21ms，雖然看上去并不久，但若和其他監聽同時執行，加上引入業務代碼的複雜性和移動端更弱的 CPU 性能，極有可能成為給業務帶來 longtask 的罪魁禍首。性能監控性能成為了瓶頸。
接下來，我們将性能監聽一個個拆分，用同樣的方式單獨測試每一個性能監聽的耗時。在實際的 benchmark 結果中，我們發現 fp、fcp、lcp、cls 監控耗時最大，加在一起超過了10ms，占了一半以上，是我們之後需要重點優化的地方。
除此之外利用 puppeteer 的能力，我們不僅可以得到 benchmark 的結果，還可以擷取到整個 benchmark 過程的 profile 資料，利用 speedscope 繪制出函數執行過程中的火焰圖：
💡 繪制火焰圖的具體實作不在本文讨論範圍内，感興趣的同學可以參考 speedscope 官方文檔
此處顯示的時間為該用例執行總耗時（單次耗時*次數）
如何衡量異步任務性能？
Benny 的 api 是支援異步測試用例的，測量的是每個異步函數從開始執行到 resolve 的時間。但通常這并不是我們想要的衡量的資料，因為異步任務的執行過程中并不是一直占據着主線程。對于一些異步的定時任務（例如 SDK 的崩潰檢測、卡頓檢測、白屏檢測），将他們拆解為一系列可測的同步任務能更直覺的展示各個階段的性能耗時。
例如我們 SDK 的前端白屏檢測，由一個 mutationObserver 和觸發白屏檢測的函數組成。我們可以單獨對 mutationObserver 的回調和觸發函數做性能衡量。
這兩個方法已沒有很好的優化方式了。但是根據 benchmark 結果并結合源碼可以發現，性能監控所有名額項的開啟均為同步執行，每一項名額都會對頁面做事件監聽或者 PerformanceObserver 監聽，且這些原生監聽耗時都在毫秒級。于是我們對性能做了如下優化：
- 性能監控邏輯分片運作，将各項性能名額的監聽同步拆為異步，用 requestIdleCallback 做排程并區分優先級。
- 多個性能名額監聽同一事件的公用監聽器，例如 CLS 和 LCP 都需要監聽 onBFCacheRestore，讓他們隻做一次 addEventListener。
- 可以延遲執行的方法延遲執行，例如在高版本的 Chrome 中 PerformanceObserver 是有 buffer 的，可以直接擷取到調用之前的性能名額，這些方法調用就可以等待頁面完全加載完成之後執行，進而盡可能減少對業務頁面首屏影響。
通過 Perfsee 的 Lab 結果分析性能問題
以上的 benchmark 流程得到的結果畢竟是一種理想化、單純的方法調用的性能情況，然而在實際浏覽器環境中我們前端監控 SDK 對性能影響有多大呢，對于這一類頁面初始化即加載的 SDK 可以通過 Perfsee 的 Lab 功能進行性能衡量。
Perfsee 是一個針對前端 web 應用在整個研發流程中的性能分析平台。提供性能分析報告、産物分析報告、源碼分析、競品分析等子產品，定位與梳理性能問題，提供專業的優化方案來漸進地優化産品性能。Lab 子產品性能分析的依據是，使用 headless 浏覽器運作使用者指定的頁面，通過運作時資料的收集，分析并産出關鍵性能名額分數、網絡請求資訊、主線程 JS/渲染/Longtask 資訊供業務方參考優化。具體使用說明請檢視 perfsee.com
💡 注意，本文所展示 Perfsee 功能示例為早期版本，并不與開源版本功能和界面完全一緻。
準備基準頁面作為對照組
我們的目的是衡量 SDK 對業務性能造成的影響，便需要找到一個基準頁面作為對比。此處以 React Server Component Demo 為例作為基準頁面。該應用有以下幾個特點：
- 容易搭建，一個指令就能跑起來。
- 自身邏輯簡單，性能好，SDK 所造成的影響容易被放大觀察。
- SPA 應用，含有異步加載的邏輯，更容易探測到監控 SDK 對頁面 FCP、LCP 等名額影響。
- 無外部網絡請求，頁面結果穩定不易波動。
我們修改一下應用的邏輯，能夠通過 url 參數注入監控 sdk 腳本，把它部署在伺服器上。接着，我們在 perfsee 平台上配置好基準頁面和注入 SDK 的頁面這兩個 page，并觸發一次性能掃描。
檢視 Lab 性能報告
我們将沒有注入 SDK 的頁面作為空白組(empty)，注入了 SDK 的頁面作為實驗組(with-sdk)。
首先我們需要配置好空白組和實驗組的 pages 以及 profile，觸發一次 snapshot 之後，我們得到了多份報告，我們可以點選 compare 将空白組和實驗組的資料進行比對。
在實際的 lab 性能掃描結果中，我們可以看到兩個頁面所有性能名額的對比。我們發現 sdk 的注入在 mobile profile（4倍降頻） 下還是給業務帶來了 fcp 70ms、lcp 90ms、load 200ms 的劣化。
同時我們還可以觀察到注入了 sdk 之後，fmp 和 lcp 之前的請求僅多了1個，這是符合預期的。不過這仍是我們保持觀察的名額之一，因為在一些中低端的環境中，頁面加載完成之前每發出一個請求就可能讓業務更高優先級的請求被延後，進而引起頁面性能名額的下降。
切換到 Breakdown Tab，我們還可以看到頁面首屏時間線。我們需要重點關注幾個關鍵名額（load、fcp、lcp）之前的線程占用情況，hover 在 load 之前這一黃色色塊上，我們發現 sdk 在 load 之前執行了30ms，成為了拖慢了業務名額的原因之一。
此處截圖省略了一些内部資訊，一般情況下，如果需要更多資訊可以借助 Source 子產品來找到引起主線程密集計算的代碼位置。
在這個例子中，這個調用未觸發 longtask，并且我們很容易發現這就是 SDK 初始化的邏輯，也是接下來需要優化的地方。
問題分析與性能優化
通過上述 benchmark 工具和 perfsee lab 性能分析結果，我們可以看出 SDK 初始化邏輯以及大量的事件監聽确實對業務性能造成了一定影響。例如上文火焰圖中所示每一個
onBFCacheRestore
都占用了超過 15ms 的時間，我們在源碼裡搜尋這個函數，此部分僞代碼如下：
const onBFCacheRestore = (cb) => {
addEventListener('pageshow', (e) => {
if (e.persisted) cb(e)
}, true)
}
BFCache 即 back-forward cache，可稱為“往返緩存”，可以在使用者使用浏覽器的“後退”和“前進”按鈕時加快頁面的轉換速度。這個緩存不僅儲存頁面資料，還儲存了 DOM 和 JS 的狀态，實際上是将整個頁面都儲存在記憶體裡。如果頁面位于 BFCache 中，那麼再次打開該頁面就不會觸發 onload 事件。
可以看到，耗時主要由 onBFCacheRestore 和 onHidden 兩個方法中的原生 addEventListener 造成。這些監聽本身都是在毫秒級的，回調函數也沒有什麼優化空間，從實際場景考慮，這兩處回調是為了監聽使用者頁面前進和傳回的，并非優先級最高的任務。我們可以從以下幾個方面降低對業務造成的影響：
1. 監控任務切片運作，區分優先級
對于監控 SDK 而言，除了必要的監聽以及事件預收集等任務，其他任何任務不應該阻礙到業務代碼的執行。對于位元組前端監控需求而言，異常和請求監聽為必須前置執行的任務，其他所有事件監聽可以拆分為單獨的任務，所有的采樣、資料運算、上報請求等資料後處理邏輯隻在空閑時執行，通過 requestIdleCallback 調用。
2. 減少重複監聽次數
多個性能名額監聽同一事件的公用監聽器，例如 CLS 和 LCP 這兩個名額都需要監聽 onBFCacheRestore，讓他們隻做一次 addEventListener。
3. 請求數量的優化
我們 SDK 的腳本是由一個必須最先執行的主腳本（包含預收集、請求hook、錯誤監聽等邏輯）和多個通過不同配置開啟的異步插件腳本（性能、資源、白屏等）組成，主腳本的請求無法省略，而插件腳本可以通過接入 cdn combo 服務或自行搭建 combo 服務将多個請求合并成一個。對于事件上報請求，我們在内部維護一個緩存，隻有當間隔達到一定時間或者累計一定數量之後才會統一上報。在這個場景中，我們又需要考慮兩個問題：
- 浏覽器對請求并發量有限制，是以存在網絡資源競争的可能性
- 浏覽器在頁面解除安裝時會忽略異步ajax請求，而同步 ajax 通常在現代浏覽器中已被禁用
我們可以通過使用 navigator.sendBeacon 方法解決上述問題。
這個方法主要用于滿足統計和診斷代碼的需要，這些代碼通常嘗試在解除安裝（unload）文檔之前向 Web 伺服器發送資料。過早的發送資料可能導緻錯過收集資料的機會。然而，對于開發者來說保證在文檔解除安裝期間發送資料一直是一個困難。因為使用者代理通常會忽略在事件處理器中産生的異步unload (en-US)
XMLHttpRequest
經過以上優化後，我們注入優化過後的 SDK 再次跑分。
優化後的 SDK 對業務 FCP、LCP、LOAD 等性能的影響已經降到了最低，已經達到了非常高的性能标準。
了解更多
位元組内部衆多業務方使用的前端監控解決方案已同步在火山引擎上，無論是外部企業開發者或個人開發者，均可通過接入該服務提升性能優化的效率。