有奖捉虫:办公协同&微信生态&物联网文档专题 HOT

实践背景

对于前端来说,最重要的是体验,而在前端体验中,最为核心的就是性能。本文将指导您如何看懂 RUM 可视化图表,并通过图表性能数据进行应用优化。

实践步骤

优化举例

下列某测试应用作为本次优化案例。前端架构错综复杂,不同应用的分析数据和优化方式截然不同,此处仅以个别应用为例,给您提供应用优化思路。n


如上图,首屏时间达到了 4.8s,LCP(最大内容绘制) 的时间超过了 4s, 指标建议优化等级也仅在“POOR(较差)”等级 ,CLS(累积布局移位) 为0.64,数据也不容乐观。那我们该如何进一步分析?
说明

LCP(Largest Contentful Paint - 最大内容绘制):LCP 度量从用户请求网址到在视口中渲染最大可见内容元素所需的时间。最大的元素通常是图片或视频,也可能是大型块级文本元素。
CLS(Cumulative Layout Shift - 累积布局移位):CLS 会衡量在网页的整个生命周期内发生的所有意外布局偏移的得分总和。得分是零到任意正数,其中 0 表示无偏移,且数字越大,网页的布局偏移越大。
FID(First Input Delay - 首次输入延迟):从用户首次与您的网页互动(单击链接、单击按钮等)到浏览器响应此次互动之间的用时。此衡量方案的对象是被用户首次点击的任何互动式元素。

分析 Top 访问页面

进入 “页面性能-页面性能 TOP 视图” ,按 “首屏时间” 倒排序,排查是否把多个应用的页面都使用了同一个业务系统进行上报,导致一些比较差的页面对整体数据产生了影响。如有,建议不同应用使用不同的业务系统上报数据,方便定点发现问题。n

n如上图我们发现开发者把多个应用的页面都在同一个业务系统上报了,导致整体性能数据较差。我们再进行下一步排查。

按网络和区域分析性能数据

排除了页面的干扰,我们再分析一下网络和区域干扰。从图中可以看出来,网络状况和地区差异对页面首屏时间变化并不大。n



再分析页面加载瀑布图

从图中可以看到该应用主要的瓶颈其实在 “资源加载” 的耗时。n


通过“F12控制台功能”对用户页面的资源加载情况进行分析,某 JS 文件达到了1.7M导致加载缓慢。n


再进一步分析,该测试应用使用的是 React 框架,在没有服务端渲染的情况下,页面是会在加载主 JS 后才渲染的。而用户大部分 JS 文件都打包成一个 bundle ,导致产生了一个超大的 JS 文件,这个 JS 文件就成为了用户页面渲染的瓶颈。除此之外还发现了该 JS 文件没有支持 HTTP2 协议。那我们该如何优化?

资源加载优化

根据上述数据显示,我们建议用户做以下优化:
1. 拆包,通过把公共外部依赖打包成为 vendor,并且对组件做异步加载。
2. 去掉一些非必需的包,例如用户引入了全量的 lodash,让其改成 lodash-es,方便 webpack 做 treeshaking;去掉仅为了把某个时间做格式化而引入的 moment;去掉 jquery,大多数 jquery 仅为了查询某个元素。
3. 建议使用 webpack-bundle-analyzer 对打包后的代码进行分析,查看哪些包不需要引用,或者可以单独打包。
4. 网络协议方面全面引入 HTTP2,合并了一些小的静态资源,把一些小的 svg 改成了 base64。
通过上述步骤优化后首屏耗时从 4.8s 优化到 3.2s,最重要的是 “资源加载” 耗时直接下降50%。



初次优化后,又迎来了一个问题,用户的 “资源加载” 时间已经大幅度降低了,但是为什么 “首屏耗时” 没有相应的同比降低(下降50%)呢?
我们通过对页面分析发现,该页面在加载完成后,会执行非常多的 JS 代码逻辑,包括一些数据上报,用户行为收集,还有加载侧边栏,弹出广告等。这个原因直接导致下列两个问题:
1. 页面主进程阻塞严重,Aegis SDK 的一些逻辑在执行的时候受到了影响,导致实际执行时间要晚于设定的时间,所以上报的“首屏耗时”其实要比实际晚的。
2. 用户的页面会在首屏完成后,继续加载很多 DOM 元素,也就是有很多 DOM 元素的变化,导致了 Aegis SDK 计算出来的首屏时间也要晚于真实的“首屏时间”。
根据上述两个问题,我们对定时器和异步进行了改造,又大幅度提升了页面的“首屏时间”。n


此时“首屏耗时”已经是优化之初的 1/2 了,但是 CLS 的得分一直是 “POOR” 的状态。需要我们对 CLS 再进行优化。

CLS 指标优化

CLS 指的是页面布局偏移量,再次简单分析,我们发现该应用有一个长列表是页面主要渲染内容,由于数据不多,一般在 4 - 10 条数据,所以开发者没有对列表做分页。
没有分页带来了列表无法在渲染之初就确定长度,导致获取数据后渲染列表的时候页面发生较大的偏移,同时也带来了超多的 DOM 变化。n这个是导致 CLS 数据较大的核心原因,同时也增加了“首屏耗时”的压力 ,除此之外,前面提到的一些异步数据,如广告挂件等也带来了DOM 变化。
于是我们做了如下优化:
1. 在一开始就确定列表高度(加入分页),通过骨架屏优化加载效果,同时减少 DOM 变化。
2. 广告挂件使用绝对布局,使其脱离文档流,减少DOM变化。
3. 一些其他元素,如图片等,确定长度和宽度属性,这些值允许浏览器在将图像渲染到位之前保留视觉空间。
4. 一些元素的变化,通过 CSS 实现,而不是使用 JS 改变元素属性实现。
再次优化后用户页面首屏和 CLS 数据变化惊人,首屏耗时下降了61.5%。下列为优化后的效果:n