埋点SDK，我是如何让甲方的页面卡顿10s+

最新推荐文章于 2025-05-09 22:33:29 发布

winty~~

最新推荐文章于 2025-05-09 22:33:29 发布

阅读量106

点赞数

文章标签：前端

原文链接：https://mp.weixin.qq.com/s?__biz=MzI0MzIyMDM5Ng==&mid=2649853117&idx=1&sn=e691df4340cb990290134e03079e640b&chksm=f175467ec602cf6881e98e50e78412d9e59e648b514d063cb233c41ef15b28b1a3ec9a56b84a&scene=126&sessionid=0

版权

前端Q

我是winty，专注分享前端知识和各类前端资源，乐于分享各种有趣的事，关注我，一起做个有趣的人～

公众号

点击上方前端Q，关注公众号

回复加群，加入前端Q技术交流群

背景音：

Sir，收到線報啦，今日喺生產環境用戶訪問網頁嘅時候，竟然感受到咁卡卡地！完全冇得爽啊！已經導致唔少用戶投訴。根據推斷，昨日更新咗埋點SDK...

昨日，一位前端程序员在优化公司的埋点SDK使用方式后，出了一些小插曲。不知道是什么原因，更新之后就开始有用户反馈说网页卡卡地，走得比蜗牛还慢。六点二十分，第一个用户提交了投诉工单，但这只是个开始。

今天早上九点十分，公司的运维团队已经接到了一大堆反馈工单，许多用户都遭受到了同样的问题。这是一个巨大的问题，一旦得不到解决，可能导致数万的用户受到影响。运维人员立即开始了排查工作，想要找出问题所在。

经过一个小时的紧急排查，他们终于想到了昨日的这名前端程序员，一经沟通发现是SDK版本更新引起的问题。在新的版本中，有一些不稳定的代码导致了性能问题。

然而，这不仅仅是个技术问题，因为接下来，他们要开始着手写事故报告，准备给上层领导交代。

接下来，进入正题：

一、问题排查定位

根据更新的版本体量，可以缩小和快速定位问题源于新引入埋点SDK。

打开开发者工具-性能分析，开始记录
刷新页面，重现问题
停止记录，排查分析性能问题

如上图，按照耗时排序，可以快速定位找到对应的代码问题。

首先把编译压缩后的代码整理一下，接下来，深入代码一探究竟。

⏸️暂停一下，不妨猜猜看这里是为了干嘛？

🍵喝口茶，让我们沿着事件路径，反向继续摸清它的意图吧。

这里列举了231个字体名称，调用上文的 detect() 来分析。 ⏸️暂停一下，那么这个操作为什么会耗时且阻塞页面渲染呢？ ... 休息一下，让我们去看看这段代码的来龙去脉。上面我们大概猜到代码是用于获取用户浏览器字体，那就简单检索一下 js get browser font。

证据确凿，错在对岸。

二、解决问题

相信大家也看出来了，我不是埋点SDK，我也不是甲方爸爸，我只能是一位前端开发。

联系反馈至SDK方，需要走工单，流程，而这一切要多少时间？

我唔知啊！领导也不接受啊！

👐没办法，只能自己缝补缝补了。

那么如何解决呢？

尝试修复 getFonts detect 字体检测逻辑，避免多次回流导致性能问题。

关于回流问题的一些文章 web.dev 官网文档

缩短待检测字体目录。

人生苦短，我选方案3，直接修改返回值，跳过检测。

getFonts () { return 'custom_font' }

那么让我们继续搬砖吧。

寻根

首先找到 SDK 加载对应 JS 的加载方式，看看能不能动点手脚。这里可以看到，是采用很常见的通过 appendScript loadJs 的方案，那么就可以复写拦截一下 appendChild 函数。

正源

通过拦截 appendChild，将SDK加载的JS改为加载修复后的JS文件。核心代码如下：

var tempCAppend = document.head.appendChild
document.head.appendChild = function (t) {
    if (t.tagName === 'SCRIPT' && t.src.includes('xxx.js')) {
          t.src = 'custom_fix_xxx.js'
    }
    return tempCAppend.bind(this)(t)
}