端性能优化是指通过一系列的技术手段和优化策略,提高网页的加载速率和用户体验。下边是一些后端性能优化的方案:1.页面渲染优化:-降低HTTP恳求:合并和压缩CSS和JavaScript文件,使用CSSSprites技术来降低图片恳求。-延后加载:将非关键资源(如图片、视频等)的加载延后到页面其他内容加载完成后再进行加载。-使用CDN加速:将静态资源布署到全球分布的CDN节点上,推进资源的加载速率。-使用懒加载:只加载当前可见区域的内容,延后加载其他区域的内容。2.打包优化:-代码分割:将代码根据功能模块进行分拆,按需加载,降低首次加载的文件大小。-TreeShaking:通过静态剖析,除去未使用的代码,降低打包后的文件大小。-按需加载:依照路由或用户操作,动态加载所需的模块和组件,降低初始加载的资源。3.总体优化:-缓存优化:合理设置缓存策略,借助浏览器缓存、CDN缓存、本地缓存等,减轻重复恳求和数据传输。-压缩资源:对CSS、JavaScript、HTML等静态资源进行压缩,降低文件大小,提升加载速率。-降低重画和回流:通过优化CSS款式和DOM操作,降低页面的重画和回流,提升渲染性能。-使用WebWorkers:将一些历时的任务放在WebWorkers中执行,防止阻塞主线程。
升商城系统的页面加载速度与进行SEO优化是提高转化率的关键策略。以下是一些具体的操作建议:
综合运用以上策略,不仅可以提升用户在商城的浏览体验,缩短页面加载时间,还能通过SEO优化增加搜索引擎可见度,吸引更多潜在客户,最终提升转化率。
灏 大淘宝技术 2024年07月15日 18:04 浙江
最近做了一些移动端页面的首帧优化的工作,有很多心得和感受,其中有很多共性的东西,总结成一篇文章希望可以帮助到更多业务,也希望引起读者一起讨论。
为何要做首帧优化
作为程序匠人,一直在努力追求做一款好的产品,打磨各个细节,做好用户体验,而首帧是用户接触到产品的第一个页面,是体验的重中之重。也正因是产品的第一个页面,转化率接近100%,从ROI的角度来说,做好首帧优化也是一个很划算的deal。
做好首帧优化,至少可以带来以下好处:
首帧口径和衡量标准
做优化前我们需要先想想,用户对首帧体验预期是怎样的?首帧定义是什么,起始范围是什么。不同的口径会影响我们的指标,设计方案,工作量。定义了口径之后,我们可以确定优化事项范围以及边界。
Loading图:
即开始出现loading、展现灰底图或是页面框架图,如果这页面展示也比较久的话,则说明用户交互出现卡顿、假死,迟迟没收到反馈,用户交互被阻塞,属于严重影响用户体验的行为。所以建议在展示骨架图之前,除了framework以外,不要有io、网络等耗时的前置依赖,也不需要有中转页的行为逻辑。
内容主体呈现:
即页面大部分的内容已经渲染出来,用户可以得到足够的信息,这是一个比较符合用户体感的口径,大多数业务选取的就是这个口径。不过不同业务对于“大部分”,“主体”的定义有所不同,业务可以结合自身需求进行合理选择:
页面可交互:
这个阶段表示页面已经完全渲染完成,并且用户可以进一步交互,如点赞、分享、收藏、加购等行为。
绝对耗时:
指定口径下的绝对耗时时长,单位一般是ms,多是用于单机线下的验证和比较,不同机型之间、不同场景下的差异较大,如高端机与低端机之间的差别可以相差好几倍,如要反应样本的整体性,多用分位值或者秒开率来衡量。
分位值/秒开率:
取值标准:
如何分析排查性能问题(以Android为例)
首先要掌握自身产品以及行业竞品的首帧数据,了解在行业中的一个排名情况,再决策是否要进一步做优化,做到什么样的程度。为了保证自身和竞品采用的同一种口径获取首帧耗时,我们这边采用了录屏的方式。
录屏分析方案:在同一台手机上使用特定帧率录屏(如30fps,即1帧33ms),再通过数帧数的方式来计算出首帧耗时的时间,录屏的越高越精确。
自动化脚本方案:
通过自动化录屏脚本工具、使用模拟点击 + OCR文字识别/图像识别的方案,识别首/尾帧、进而自动化生成耗时的中位数、平均值。
在分析问题之前,我们要搞清楚系统是如何将首帧绘制在屏幕上的,了解了这些我们才能针对性的分析问题。
从代码、资源等细粒度的维度(如方法级别、事件级别),来定量分析程序对CPU、内存、网络IO等核心计算资源的消耗情况,可以比较完整、全面的分析启动过程,但这种方式得到的数据比较细碎、散点,需要经过一定的归纳、合并才能得到一个具体可实施的方案。
如果我们的页面是通过第二/三方的页面框架所构建,如weex/rn/flutter等框架。我们可以通过第二方框架提供的性能分析工具、插件去分析和归因。
有时为了弥补官方工具火焰图太细碎、难以聚类、需要花费更多时间去分析和追踪,我们可以根据业务视角、使用自定义的业务阶段/流程,去粗粒度的去分析各个阶段的耗时。
常见的优化方案和策略
分析完原因后,我们需要对不同原因给出优化方案,首帧优化的核心思想用一句话总结是:在尽可能在短的时间里准备好首帧渲染所需要最小的资源模型。围绕“最短时间”和“最小的模型”两个中心思想下,总结了一些常见的优化策略:
在前置页面的合理时机(一般是闲时)提前获取数据、下载资源,并解析,然后缓存到内存或者磁盘里,以便后置页面快速读取数据和资源。
这个策略可能带来以下副作用:
与首帧无关的代码逻辑、资源可以在首帧渲染后进行初始化,具体的初始化时机可以在使用时再初始化,如某些二级页面的创建、多余tab的创建等。
并行处理:充分利用多核CPU,通过多线程并行处理耗时的任务,提升CPU的负荷。如容器初始化和数据请求解析可以同时进行。
异步化:一些比较耗时、IO任务,不要占用宝贵的主线程资源。
Android里面ViewTree构建和渲染是比较耗时过程的,如下:
优化方案:
为了加快数据获取,我们可以从前一个页面借用一部分数据过来将主体内容做填充,随后再用真实数据刷新。这个方案多适用于列表进入详情的场景。
这里的数据不仅包含文字和图片,也可以延伸到媒体播放器、camera取景器等其他一些文件流、数据流,甚至可以是widget组件(共享元素动画)。
如果页面元素比较多,数据量比较大,一次性请求加载的时间比较长,这个时候我们可以通过分块的方式,将大页面拆成若干个小页面模块、将服务端接口拆成若干个小接口,各个页面模块独立渲染。可以有效降低服务端RT耗时,以及页面渲染耗时。
使用骨架图作为打底图和纯白底图相比,有了布局样式等信息,更加接近于首帧的效果,正式数据刷新时,页面也不会出现明显刷新,体验比较好。
线上验收
线下的优化,并不意味着线上真实用户也能同步看到优化的结果,因为业务路径的差异、机型的差异,你线下的优化可能不具备普遍性,所以需要线上真实结果的反馈。
包含:版本、设备分、业务场景、机型、时间等尽可能多的数据维度的数据大盘,可以尽量还原优化or劣化的信息全貌,提供更多的归因信息。
长尾数据、小众case往往容易被整体数据给覆盖,不足以引起重视,为了我们应该分别分析中位数、分位数。
这样做不仅能控制变量确保优化项的严格有效,还能借此来观察性能优化所带来的业务指标收益,这些都可以作为规划后续启动优化方向的参考指导。
防劣化
人无完人,人都会失误犯错,绝对不能把系统性能交给某一个人身上,一个人犯错概率高,一群人都犯错的概率低,应该交给一群人共同协作的机制和流程。
防劣化相比于优化是更能持久有益的,所以更应该在较早期建立起防劣化机制:
结语
首帧优化并非一蹴而就,而是一个需要持续迭代与打磨的过程,在初期阶段优化空间相对较大,只需要投入一些不多的资源,即可看到较大的收益,但随着优化不断深入,到了中期阶段,就需要有相当程度的投入,去攻坚各个难点,聚少成多,才能看到收益。后期随着业务越来越复杂,分支越来越多,要做防劣化工作,同时也要和业务一起做好精细化管理,将有限的资源,分配给最优先级的业务,要做好ab实验管控、优先级管理、及时下线等。
为了将达到最优的启动速度,我们运用了各式各样的策略,将时间和空间塞得满满的,但是这改变了原来的常规流程,带来了额外代码复杂度提升,比如预加载策略,后面维护同学需要考虑,预加载失败以及成功两种情况,又或者是缓存策略,后面维护的同学需要考虑缓存命中、不命中的情况,如果不断使用if堆积代码,那代码最终将无法维护。所以我们需要通过框架来管理复杂度,尽量让业务层无感知。比如数据中间层,业务无需关心数据是否来自缓存还是实时请求,拿来使用即可。
通常我们以启动速度来衡量启动性能。为了提升启动速度,我们可能会把一些原本在启动阶段执行的任务进行延后或者按需,这种方式能够有效优化启动速度,但同时也可能损害后续的使用体验。比如,如果将某个启动阶段的后台任务延后到后续使用时,如果首次使用是在主线程,则可能会造成使用卡顿。因此,我们在关注启动性能的同时,也需要关注其他可能影响的指标。性能上我们需要有一个能体现全局性能的宏观指标,以防止局部最优效应。
参考资料
团队介绍
我们是淘天集团-内容技术团队,专注于推动淘宝内容生态和电商体验的深度融合。我们致力于为全球用户提供丰富、多样性、高品质的购物内容体验,旨在通过技术创新,更好地连接用户和商品,以提升用户的购物满意度和平台的商业价值。通过尖端技术提升内容创作、分发与消费的效率,赋能内容创作者、商家与消费者,构建一个繁荣、健康、可持续发展的内容生态圈。
*请认真填写需求信息,我们会在24小时内与您取得联系。