前端质量｜基于业务驱动的前端性能有效实践案例

简介：前端的本质价值是什么？作者认为是给用户创造良好的交互体验和抵达率优化应该在转化率之前。那么本文就将和大家分享基于业务驱动的前端性能有效实践案例。

作者 | 钱文玲(悠酱) 来源 | 阿里开发者公众号

一、背景

1.1.前端性能优化的业务意义

前端的本质价值是什么?

我认为是 给用户创造良好的交互体验。前端性能对用户体验、对业务跳失率的影响，在业界已有共识，不言而喻。根据 Google 的数据，如果移动站点的加载时间超过 3 秒，53% 的用户会放弃访问。

加载时间从 1s 延长到 3s 时，跳失率增加32% 加载时间从 1s 延长到 5s 时，跳失率增加90%——用户还没看到辛苦优化的页面，就走了一部分 。

（参考文末链接）

抵达率优化应该在转化率之前，用户能够正常访问网页，网页的内容才能产生价值。所以在优化着陆页内容、提高转化率之前，要先保障抵达率。抵达率太低，哪怕页面转化100%，整体的转化效果也会很差。

1.2.测试把控难点

• 现在流行的，运营自行搭建页面+自行多端投放 方式，使我们的不可控。
• 原先发现性能问题主要通过感受+性能跑测数据，或者运营以业务要挟、或者质疑受机器等因素影响、或者相互推诿主要瓶颈点，使优化无法落实。
• 部分性能优化困难，影响性能点比较复杂，实行优化的收益不可预知，也阻碍了优化的落实。

二、前端性能优化 测试视角的解法

很多人都以为，前端性能优化，重点在“前端”优化，“测试”很难起到主导作用。试着换个角度，从整个研发团队视角看，前端做运动员专项治理，测试做裁判员专项评测，这套机制，是否更能切实做到优化，达成的数据也更让大家信赖？再者，测试不止局限于此，还可做队医、分析师。。。。

2.1.可持续优化闭环

以下持续优化闭环，是我们摸索着实行了一年多，有效且高效的解法。

从上图看，整个过程为：

step0、前端事先进行埋点，（一般前端做了sdk，直接引入即可）

step1、测试通过性能黑榜，发现最为突出的重点性能问题页面（首屏平均时长&秒开率，PV&业务意义， 多项结合度量）

step2、协助前端一起专业分析问题页面，找出性能瓶颈点

step3、前端更有策略地针对性治理

step4、查看性能趋势变化，验证优化效果

step5、假设已达到优化预期，或者有更糟糕的页面把之前页面挤下去，继续关注黑榜前列的页面（即跳到step1，继续轮转）

我们可以发现，测试通过发现、分析、验证 三板斧，驱动推进页面性能优化。

2.2.效果明显

从2021年10月份开始迭代以来，共发现了8类严重性能问题。

包括：端外（支付宝）性能问题，外投&跨端性能问题，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.统计范围--用户视角

所有前台页面，每个用户每次浏览的有效数据（完全加载