前端监控闭环：采集、告警到问题跟踪

wuwenzen@outlook.com (wuwj) — Mon, 05 Sep 2022 00:00:00 +0000

很多团队做前端监控的姿势是：

先接一个 SDK，看到了几个报错，然后就没然后了。

最后变成：

告警群天天响，大家学会了「静音」；
仪表盘很酷，但没人看；
真出大问题时，还是靠用户截图。

这篇文章想聊的是：怎么从「有监控」升级到「有闭环」：采集、告警、问题跟踪、复盘一条链路打通。

1. 前端到底要监什么？

可以按三个维度来想：

可用性
- JS 运行错误（Error、Promise 未捕获）；
- 资源加载失败（JS/CSS/图片）；
- 页面白屏/异常重定向。
性能
- 首屏指标（FCP/FP/TTI 等的近似值）；
- 接口耗时、失败率；
- 静态资源加载时间。
行为 & 转化
- 关键路径的曝光/点击/完成；
- 异常行为（频繁刷新、某步流失明显）。

实践上，可以先从：错误 + 性能 + 关键链路打点 三件事做起。

2. 采集：埋点 & SDK 一起用

2.1 错误采集

典型方式：

window.addEventListener('error', (event) => {
  reportError({
    type: 'error',
    message: event.message,
    filename: event.filename,
    lineno: event.lineno,
    colno: event.colno,
    stack: event.error?.stack,
  });
});

window.addEventListener('unhandledrejection', (event) => {
  reportError({
    type: 'unhandledrejection',
    reason: String(event.reason),
  });
});

结合 sourcemap 上传，可以把错误还原到源代码行。

2.2 性能采集

利用 Performance API：

一次性能优化实战：从 5s 到 1.5s 的页面加载

wuwenzen@outlook.com (wuwj) — Thu, 14 Jul 2022 00:00:00 +0000

有一次线上迭代后，陆续收到反馈：

「系统能用，就是打开慢了一截。」
「首页白屏时间变长了。」

监控一看，某个核心页面的首屏时间从 约 2s 抬升到了接近 5s。
这篇文章就是那次性能优化的实战复盘：我们如何量化问题、定位瓶颈、再一步步把首屏拉回到 1.5s 左右。

1. 先量化，而不是拍脑袋

第一步是搞清楚「慢」在哪：

首包下载？
JS 执行？
接口耗时？
还是一堆「非必要逻辑」抢在首屏执行？

我们主要用了三种手段：

Chrome DevTools Performance 看关键时序；
Lighthouse 跑实验室指标；
前端埋点 看真实用户数据（FMP/TTI 的简化近似）。

初步结论：

JS 资源总体体积较大，首屏要加载的 JS 超过 1MB（压缩后）；
首屏渲染完成前存在一段较长的 JS 执行（主线程被占用）；
首屏接口本身不是特别慢，但被一些不必要的请求夹在中间。

目标明确：瘦 JS、少阻塞、分优先级。

2. Bundle 拆分：让首屏只拿它真需要的

2.1 分析构建结果

接入 webpack-bundle-analyzer / Vite 插件之后，很快看到几个「大头」：

整个 UI 组件库全量引入；
某些图表库（在其他页面才用）被打进首屏 bundle；
若干工具库重复/未 Tree-shaking。

2.2 做的调整

组件库改为按需引入
- 把 import ElementUI from 'element-ui' 改成 babel 插件/手动按需；
- 打包结果里组件库体积明显下降。
路由级别代码拆分

性能 on Saiga