前端监控系列4 ｜ SDK 体积与性能优化实践( 四 ) _生活百科

性能监控逻辑分片运行，将各项性能指标的监听同步拆为异步，用 requestIdleCallback 做调度并区分优先级。
多个性能指标监听同一事件的公用监听器，例如 CLS 和 LCP 都需要监听 onBFCacheRestore，让他们只做一次 addEventListener 。
可以延迟执行的方法延迟执行，例如在高版本的 Chrome 中 PerformanceObserver 是有 buffer 的，可以直接获取到调用之前的性能指标，这些方法调用就可以等待页面完全加载完成之后执行，从而尽可能减少对业务页面首屏影响。

通过 Perfsee 的 Lab 结果分析性能问题以上的 benchmark 流程得到的结果毕竟是一种理想化、单纯的方法调用的性能情况，然而在实际浏览器环境中我们前端监控 SDK 对性能影响有多大呢，对于这一类页面初始化即加载的 SDK 可以通过 Perfsee 的 Lab 功能进行性能衡量。

Perfsee 是一个针对前端 web 应用在整个研发流程中的性能分析平台。提供性能分析报告、产物分析报告、源码分析、竞品分析等模块，定位与梳理性能问题，提供专业的优化方案来渐进地优化产品性能。Lab 模块性能分析的依据是，使用 headless 浏览器运行用户指定的页面，通过运行时数据的收集，分析并产出关键性能指标分数、网络请求信息、主线程 JS/渲染/Longtask 信息供业务方参考优化。具体使用说明请查看 http://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，成为了拖慢了业务指标的原因之一。