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