1、背景
在聊前端性能问题前，首先给大家看一下美间工具下常见的操作示意图，这里是用户方案数据加了特定内容后，在画布内对单张图片进行拖动操作
上图是优化前的效果，下图是优化后的效果
下面是在打开方案时，整个方案所有资源加载完的耗时
上图是优化前的效果，下图是优化后的效果
就以上动图来看，除非软件真的是刚需无法替换的，相信任何人是无法长期在优化前的环境下工作。有研究表明，网页加载时间超过3秒，有一半的用户会失去耐心而离开。作为一款不断在迭代的工具类软件，前端性能跟用户体验息息相关，前端性能的好坏直接关系到用户的满意度、使用意愿以及对网站的忠诚度。日常我们不仅要保证日常用户功能的使用体验，也需要考虑性能对用户的影响。
今天就给大家聊一聊美间2D工具在前端性能问题排查的一些思路与保障方法。
2、工具前端性能问题排查难点
在前端性能问题排查过程中与跟进过程中，我们经常会碰到如：
针对用户反馈：用户是非专业的，在反馈问题时很多功能问题可以很清楚的描述出来，如“某个功能无法使用”、“某个功能在使用过程中出现什么问题”等，但是在涉及到性能问题时，往往只能表述说自己的感觉有问题，更多的描述可能是“慢”、“使用卡”、“使用不流畅”、“间接性卡壳”等，如果细问到具体操作时，也描述不清楚，甚至说刷新一下页面，或者重启一下页面就好了，如下图：
针对性能跟踪：功能问题往往跟用户环境、用户软硬件没有太多的关系，但是性能问题却跟用户使用的软硬件环境，账号操作场景跟方案数据等有很大的关系。很多操作，在我们本地往往都是看似正常的，但是在用户那边却频繁的出现，所以需要频繁跟用户沟通，甚至是跟用户远程或者面对面交流，才能清楚了解用户的场景，且也不是100%就能复现的；
持续性能优化：日常性能也会随着需求的迭代而发生变化，所以在需求测试过程中，我们不仅要关注功能，也需要关注性能的变化，但这种场景下往往面临影响面评估不全，需求上线后存在性能退化的风险；
以上的情况都会给我们排查、跟进性能问题造成一定的困扰。
3、性能问题思考
那怎么更好的解决这些问题？
3.1明确用户使用场景
如果对性能问题划分场景类型，其实我们可以明确划分出两类：
- 一类是不同场景下的内容加载，如方案加载、页面加载、图片加载等，我们可以通过“耗时”来评估出不同场景下内容加载的性能好坏；
- 一类是不同场景下的内容操作，如图片拖动、图片旋转、图片缩放等，我们可以通过“帧率”来评估出不同场景下内容操作的性能好坏；
3.2 明确跟进性能问题方向
无论是针对性能问题的反馈跟排查，还是问题的复现跟优化解决以及问题上线后的持续跟踪，都要花费很多的精力，所以我们要明确日常过程中，我们的主要关注点是哪些：
1.针对用户反馈的问题，用户的描述千变万化，我们需要快速识别和筛选用户问题，分辨出反馈的是性能问题；
2.依赖用户反馈性能问题是不现实的，工具也是不断在迭代，所以我们需要有自己的手段及早发现性能问题，那么需要建立线下的尽早拦截机制；
3.线下的无论怎么拦截，使用场景跟用户在线上实际使用场景还是存在很大的差别，所以线上的性能监控也需要建立；
3.3 明确跟进性能问题场景跟指标
在明确跟进性能问题的方向之后，我们就要考虑好怎么去筛选、建立拦截跟监控机制。目前美间的方式是明确好衡量指标跟需要覆盖的场景，然后通过埋点将数据上报后，对数据清洗建立看板、建立监控。所有的内容加载类场景，我们在埋点可以通过耗时(计量单位：ms)来监控上报，所有的内容操作类场景，我们在埋点可以通过帧率(计量单位：FPS)来监控上报，其他还需要获取用户的硬件信息，如：CPU、内存、显卡、是否开启硬件加速等；还需要分析用户的方案信息，如方案尺寸、方案元素数量、方案特效等。其实跟功能测试一样，性能的场景有很多，我们无法穷举覆盖也不可能覆盖所有的场景，所以我们在关注或者解决问题时，要区分好优先级，重要问题重点投入，轻微问题慢慢投入；
4、数据监控看板与指标保障
4.1 操作类性能问题快速识别和筛选
通过收集到的数据，在用户反馈性能问题时，我们可以通过用户账号ID，使用时间或方案ID进行筛选，轻松获取用户在特定时间段内的行为操作帧率数据。凭借这些数据，能够准确评估反馈的用户性能是否存在潜在问题。
说明：通过以上的图，我们能发现当前用户操作帧率大部分都在50fps以上，所以理论上用户的操作性能是正常的
4.2 线下性能基线看板与监控
通过埋点能获取到数据之后，我们就可以考虑，在线下通过UI自动化覆盖我们的核心场景，并不断拓展建立自己的性能基线。
在通过对基线数据进行多维度的比对推送，这样能及早地识别和发现性能问题，确保性能优化不会出现退化，保证用户体验。
4.3 线上操作性能看板与监控
通过对线上用户的数据收集，我们可以将用户的数据分为几个阶段，在美间我们根据用户操作性能差异筛选出不同区间，基础的操作帧率区间分为0-10，10-20，20-30，30以上，且可以动态调整。通过这份数据，我们能了解到目前性能用户的分布。
通过定义行为波动百分比并与同期进行比较，监测线上数据变动。发现 大幅波动时，及时推送告警以防问题扩大。
4.4 线上低性能用户定义与数据跟踪
通过收集到线上用户数据，我们划分出“定义低性能用户”人群，在美间，我们是这么定义的：
- 用户每天在美间的低帧操作为20FPS及以下的行为；
- 用户的低帧操作占比总操作次数在10%及以上；
- 一周内用户在美间工具内核心场景总操作数大于100次；
通过人群划分，我们可以得到一份低帧用户与美间工具操作用户数占比，在根据这个占比了解到我们不断做的性能优化对用户的实际影响变化。
另外，这份数据也可以有其他的用法，比如我们通过拉取这份人群用户的账号id，对这些id的一些软、硬件信息进行分析，找到其中的共同点，针对性的去解决问题；包括可以进行电话回访，定点的优化，定点的问卷调查等。
5、实践案例
5.1 案例实践1-简单的前端用户行为排查
用户反馈称使用工具操作时偶尔出现卡顿情况。通过分析用户帧率数据与硬件数据，我们发现在低帧率时段是由于使用的电脑未开启硬件加速所导致，用户开启硬件加速后，性能数据恢复正常
5.2 案例实践2-性能基线发挥作用
某次进行非核心场景的性能优化，单场景下性能提升很大，但是通过性能基线报告发现对核心场景造成很大的影响，故直接将性能优化回滚；
5.3 案例实践2-数据分析发现低性能用户占比提高
某次上线了针对某一个行为的底层细节性能优化，单看优化结果是有效的，但是上线后发现低帧用户数在不断上涨，最终回滚了这一次性能优化；
6、总结
前端性能是一个老生常谈的话题了，它不单单是一个技术概念，而是用户体验中非常重要的一环。通常在一些面向用户的产品中它直接影响了用户转化率、粘性等重要指标。
而前端性能问题的跟进与解决不仅需要团队同学的大力支持，获取数据，分析数据是性能的其中一环，怎么利用好这些数据也需要依赖科学的方式方法去不断挖掘。希望这篇文档对大家有一些启发。
作者:青墨
来源-微信公众号:酷家乐技术质量
出处:https://mp.weixin.qq.com/s/lzTbLR11basV2GNS83PfUA