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