前端性能监控概览

[fengzilong]

概览

性能监控的数据一般分为两种

1. Field data (也叫做 RUM，Real User Monitoring)
2. Lab data

Field data

即我们在用户侧统计到的性能数据

优点

• 真实，能反映最终的用户侧的页面加载体验
• 能够结合一些业务指标进行分析

缺点

• 受限于浏览器API，统计到的性能指标有限
• 一次性数据，无法调试（很难定位性能差的原因）

Lab data

最常见的比如我们用 lighthouse 得出的性能数据

优点

• 可稳定复现页面加载情况（模拟相同的运行环境）
• 可用于本地调试/定位性能问题
• 整个加载过程可视化，而不是只有一些数据产出

缺点

• 无法得知真实环境下的加载瓶颈
• 无法和业务指标结合

如何解读这两种数据

lab data

由于它最大的特点就是稳定，所以 lab data 可以帮助开发者更有针对性地优化页面的性能，以及评价优化前后的性能变化，可以结合每周一次的性能周报，帮助开发者了解页面的性能情况以及每周的优化结果

field data

来自用户侧的真实数据，这个统计到的结果是不稳定的，波动较大，所以光看性能方面数据的是没有意义的

本周性能数据较好，下周数据较差，这能说明页面出现了负优化吗？说明不了，数据出现波动不一定是开发者写了很差劲的代码

那这个数据应该怎么看呢？这个放到下面的总结里面说

总结

如果让我用几个词分别总结下 lab data 和 field data 的话，我会这样子总结

lab data

• 参考（开发者优化性能的标杆）
• 回归（页面性能出现下滑的监控）

field data

• 规律（加载性能对于用户行为的影响，这个应该是我们做性能优化的出发点）
• 验证（性能优化上线后是否对业务产生了实质的帮助）

所以回答下上面留下来的问题，field data 应该怎么看？

1. 结合业务指标（跳出率、转化率）
2. 有目的的去看（为了验证什么？）

其次，我是不推荐 field data 采用发周报形式产出性能数据的，单纯产出性能数据，如果不结合业务指标，参考价值反而不如 lab data 来得标准

field data 由于其真实性的特点，它的意义在于找出规律，用数据说服开发者进行性能优化或者验证性能优化后对业务指标的帮助

再精简下

普通开发者在优化期间应该关注 lab data

性能优化发起者/领导应该有目的性地关注 field data

图片来自 [User-centric Performance Metrics]

参考资料：

• How To Think About Speed Tools
• User-centric Performance Metrics

[Anlibraly]

总结很棒！这两件事目标是都为了用户体验。lab data在做性能优化工作中可以精细的指导和明确的告诉你页面的好坏；field data可以反应真实的用户分布情况，佐证性能在用户侧的表现是否与预期一致！

[fengzilong]

相辅相成😉