许达来|前端质量｜基于业务驱动的前端性能有效实践案例( 二 )

包括：端外（支付宝）性能问题，外投跨端性能问题， pha架构性能问题，运营不规范配置导致、其他业务原因导致的性能问题等。
并且快速有效，在业务方或其他同学提过来之前，我们都已经发现并有了分析，在优化节奏上更具有主动性。
三、性能问题的发现通过线上用户的真实采集，并制定能反应用户体感的指标，进行性能黑榜和全局趋势分析。
从重点单点角度，我们通过性能黑榜；从整体视角，我们通过整体趋势分析。
3.0.性能数据的采集
3.0.1.几个名词解释
ARMS前端监控专注于对Web场景、小程序场景的监控，从页面打开速度（测速）、页面稳定性（JS诊断错误）和外部服务调用成功率（API）这三个方面监测Web和小程序页面的健康度。
SLS日志服务为Log、Metric、Trace等数据提供大规模、低成本、实时的平台化服务。日志服务一站式提供数据采集、加工、查询与分析、可视化、告警、消费与投递等功能。
ODPS即MaxCompute ，是适用于数据分析场景的企业级SaaS模式云数据仓库。
FBI是阿里内的智能大数据分析和可视化平台，下面的所有截图都是在FBI平台配置图表而成，还未对外开放。
3.0.2.全过程
arms-sdk结合前端的自定义埋点，在海量用户访问的同时，就会自动上报数据到sls日志库，整体过程如下图：

针对H5搭建页的埋点，使用通用方案，一次性埋点即可，前端后续无需额外埋。sls日志报表查实时数据，用于实时分析，实时验证。ODPS数据长期存储已计算完指标的数据，用于记录、比较、趋势分析。3.1.性能指标的确定
3.1.1.统计范围--用户视角
所有前台页面，每个用户每次浏览的有效数据（完全加载15s 内有效）
指标的影响因子：从用户视角，页面流量越大，则对整体数据的影响越大（也就是权重越大）
这样做的好处：流量越大数值越严重的，优化的效果（正反馈）越明显，确定了治理性能问题的优先级。
3.1.2.三个指标
结合淘系、以及集团其他部门的

3.2.性能黑榜
为何要用性能黑榜来作为主要发现手段？我们通常可推理得：
排在性能黑榜前列的，必然是性能问题最突出的，相对方便分析（可根据各自业务，加个样本量的筛选，如我们看每日pv 10w以上的）
再结合样本量（pv正相关）数据，样本量非常大的，性能优化的收益必然也是非常大的模块化组件开发盛行的今天，优化某个模块或场景的问题，收益点不仅仅在当前页面，也在其他用了同样模块或场景的页面榜单形式，更能引起老板、对应前端负责同学、对用户体验关注的同学的重视 3.3.整体性能趋势分析
整体趋势分析，即是为在整体角度，看我们的页面性能趋势，它是重要的度量指标。这里我们把所有的流量都纳入，没有页面的区分，为的是基于用户维度，流量大的页面权重自然会更大。

从上图看， 1月初到2月中旬的数据正在持续恶化，必须要采取措施治理！
四、性能问题的分析（下文以2022年2月A频道页面为例，均为dummy仿造后数据，也不代表整体情况）
4.1.如何衡量性能问题严重性
衡量性能问题严重性，是为了让大家意识到优化的必要性，以及急迫性
4.1.0.进入性能黑榜前几名
同3.1.性能黑榜，不赘述
4.1.1.看完全加载时长分布
见下图“可交互时长分布图” ，一个记录代表一个用户。

即使不去统计，我们都能很明显的看出来，这个A频道页面：