引言：前端的本质价值是什么？笔者认为，为用户创造良好的交互体验，优化到达率应该先于转化率。那么本文将基于业务驱动的前端性能与大家分享有效的实践案例。作者|钱文令（右江）来源|阿里巴巴开发者公众号1.背景1.1.前端性能优化的商业意义前端的本质价值是什么？我觉得是为了给用户创造一个很好的交互体验。前端性能对用户体验和服务跳出率的影响已经成为业界共识，不言而喻。据谷歌称，如果加载时间超过3秒，53%的用户会放弃移动网站。当加载时间从1s延长到3s时，跳出率提升了32%。当加载时间从1s延长到5s时，跳出率增加了90%——用户在看到硬优化页面之前就离开了一部分。（参考文末链接）到达率优化应该先于转化率，这样用户才能正常访问网页，网页内容才能产生价值。因此，在优化着陆页内容，提高转化率之前，首先要保证到达率。到达率太低，即使页面转化100%，整体转化效果也会很差。1.2.测试和控制困难。现在流行的自建页面+自管多端投放的运营方式让我们无法自控。原来主要是通过经验+性能跑测试数据发现性能问题，或者运营受到业务威胁，或者被质疑是受机器等因素影响，或者主要瓶颈点相互转移，导致优化无法落地.部分性能优化难度大，性能点比较复杂。优化的收益是不可预测的，这也阻碍了优化的实施。2、前端性能优化测试角度的解决方案很多人认为前端性能优化重在“前端”优化，“测试”很难起到主导作用。尝试改变角度。从整个研发团队来看，前端致力于运动员的管理，测试致力于裁判的评价。这个机制能否更有效的优化，得到的数据更可信？此外，测试不仅限于此，还可以作为队医和分析师。...2.1.持续优化闭环下面的持续优化闭环是我们探索了一年多的有效且高效的解决方案。从上图看，整个流程是：step0，前端提前嵌入，（一般前端都有sdk，直接导入即可）step1，测试通过性能黑名单，最突出找到关键性能问题页面（首屏平均时长&二开率、PV&业务意义、多个综合指标）step2、协助前端专业分析问题页面，找出性能瓶颈点step3、前端有更具战略性和针对性的治理step4，检查性能趋势变化，验证优化效果step5，假设已经达到优化预期，或者有更差的页面压榨之前的页面，继续关注黑名单首页（即跳转到step1继续轮换）。通过发现、分析、验证，我们可以发现试驾。促进页面性能优化。2.2.效果明显自2021年10月开始迭代以来，共发现8类严重性能问题。包括：终端外（支付宝）性能问题、外部投资&跨终端性能问题、pha架构性能问题、运行配置不规范导致的性能问题等业务原因。而且它快速有效。在业务方或者其他同学提到之前，我们就已经发现并分析过了，更加主动的去优化节奏。3、性能问题的发现通过对在线用户的真实采集，建立反映用户体感的指标、性能黑名单和全局趋势分析。从关键点来看，我们通过了性能黑名单；从整体来看，我们通过整体趋势分析。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日志库，一次性埋点就够了，前端后续不需要额外埋点。sls日志报表查看实时数据，进行实时分析，实时验证。ODPS数据长期存储计算指标的数据，用于记录、对比和趋势分析。3.1.绩效指标的确定3.1.1．统计范围--用户视角下的所有前台页面，每个用户每次浏览的有效数据（满载后15s内有效）指标：从用户视角来看，页面流量越大，对整体数据的影响越大（也就是权重越大）。这样做的好处：流量越大，价值越严重，优化效果（正反馈）越明显，决定了治理绩效问题的优先级。3.1.2.三个指标与淘系和集团其他部门相结合。3.2.为什么要以性能黑名单作为主要发现手段？我们通常可以推断出：在性能黑名单中排名靠前的肯定是性能问题最突出的，比较方便分析（可以根据各自的业务加个样本量筛选，比如我们看dailypv10wormore）然后结合Samplesize（pv正相关）数据，如果samplesize很大，那么性能优化的收益肯定也很大。在模块化组件开发盛行的今天，优化某个模块或场景的问题，不仅可以从当前页面中获益，还可以从当前页面中获益。以使用相同模块或场景的其他页面列表的形式，可以引起老板、负责前端的同学、关注用户体验的同学的注意。3.3.整体性能趋势分析整体性能趋势分析就是看我们的页面性能趋势，这是一个重要的指标。这里我们把所有的流量都包括进去，不区分页面，因为基于用户维度，流量大的页面权重自然会更大。从上图来看，1月初到2月中旬的数据在不断恶化，必须采取措施加以控制！4、性能问题分析（以下以2022年2月A频道页面为例，均为虚假仿冒数据，不代表整体情况）4.1．如何衡量性能问题的严重性衡量性能问题严重性的目的是让大家意识到优化4.1.0的必要性和紧迫性。性能黑名单前几名与3.1相同。一条记录代表一个用户。即使我们不去统计，也能清楚的看到这个频道A页：4.1.2。看时间分布的比例和开发描述问题的严重程度，这个会很有代入感，比如看下图，10%的安卓用户在4.9s以上，是不是大部分都漏掉了？4.1.3.再来看与整体数据的对比，下图中可以明显发现二次打开率与整体数据存在巨大差异。4.2.分析性能瓶颈——分析思路首先要明确，性能分析主要是针对相关页面的前端，开发同学，测试同学关心问题，所以我们可以拆分的更细更专业.可分为前端和后端两大类：4.3.性能瓶颈分析——前端环节4.3.1．以终端（未详细展示）来分析业务因素，终端是重点。从交互时长、秒开率、3秒+率、5秒+率分别可以看出支付宝的问题更加明显。4.3.2.分阶段分析下图可视化了t1到t9各阶段的打点情况，分析了关键环节的差异（打点逻辑由前端定义）。从图2可以清楚的观察到：1.界面耗时过长，而且2.12之后退化明显（可以回溯到2.12的情况）；2.获取LBS需要很长时间，比平均高出1倍多，拿lbs是A频道页面4.3.3的关键逻辑。机器分析方面，我们根据淘宝中高端机、高端机、低端机的评价标准获取数据。平均时长，高、中、低各占比，低端时长分布（中高端也可选）。如下图可以看出，低端机占比很低（需要考虑是否需要重点优化），但是超过3秒的低端机占比远高于其他（与整体完成时间分布相比）。4.3.4.其他分析包括：模型、系统等，可作为参考4.4。性能瓶颈分析——后端环节4.4.1．后端接口分析主要是从后端维度分析server端的链接逻辑，需要单独做详细分析子页面的处理逻辑，需要结合业务逻辑看这里。下图虽然是发起请求-》接收请求的全过程，但也严重超标（几乎是标准值的两倍）4.4.2.整个接口过程的网络传输消耗分析：请求连接（apiConnect）--》服务端处理（apiRequest）--》数据下载（apiResponse）详情未列出。体量越大，性能数据优化越明显2.结合业务意义3.为前端分析提供方向，分析更详细，还是靠前端专业分析还是以A渠道为例，从数据差异、接口和lbs来看，均值差异最大。从样本量来看，支付宝流量占据了一定比例。因此，我们重点优化：界面，LBS，支付宝端。5.性能问题的验证主要是通过单页性能趋势分析，主要有两个f功能来验证性能优化效果，从而实现量化及时洞察页面性能不佳的趋势，更加主动。5.1.及时反馈业绩变差，今年1月，一个业务需求导致业绩变差。它是通过向小组发送每周绩效报告而立即被发现的。建议您定期将性能趋势图发到群里，以便您及时发现。5.2.性能优化效果验证参考链接：https://zhuanlan.zhihu.com/p/...原文链接本文为阿里云原创内容，未经允许不得转载。
