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

文章插图
在实际的 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 再次跑分。