写点什么

商智 C 店 H5 性能优化实战

  • 2024-01-03
    北京
  • 本文字数:6427 字

    阅读完需:约 21 分钟

前言

商智 C 店,是依托移动低码能力搭建的一个应用,产品面向 B 端商家。随着应用体量持续增大,考虑产品定位及用户体验,我们针对性能较差页面做了一次优化,并取得了不错的效果,用户体验值(UEI)从一般提升到良好。本文详细记录了优化思路及过程,期望给正在或打算做用户体验提升的小伙伴提供一些参考。

一、性能优化概览

从宏观方面讲,前端性能优化主要包含两个层面:


•快速的首屏响应


指的是从用户输入 URL 到页面完整渲染出来的过程中,通过减少资源请求时长、合理化页面渲染等方式,让页面内容尽快呈现到用户面前,达到舒适的展示效果。


•流畅的交互体验


指的是在资源加载且页面渲染完成后,用户与页面的交互反馈及时且动效流畅,没有卡顿、掉帧等情况。


本文重点介绍前者,性能监测工具依赖烛龙平台(性能指标来自 LightHouse 性能工具)。

二、性能分析

1、Lighthouse 工具

Lighthouse 是 Google Chrome 推出的一款开源自动化工具,它可以搜集多个现代网页性能指标,分析 Web 应用的性能并生成报告,为开发人员进行性能优化提供参考方向。

1.1 性能指标

•FCP


首次内容绘制(First Contentful Paint),是指测量在用户导航到页面后浏览器呈现第一段 DOM 内容所花费的时间。DOM 内容包括页面上的图像、非白色<canvas>元素和 SVG 等,不包括 iframe 内的任何内容。


•LCP


最大内容绘制(Largest Contentful Paint):测量视口中最大的内容元素何时呈现到屏幕上,这近似于页面的主要内容对用户可见的时间。


•SI


速度指数(Speed Index),反映了网页内容填充的速度。页面解析渲染过程中,资源的加载和主线程执行的任务会影响到速度指数的结果。


•CLS


累积布局偏移(Cumulative Layout Shift),主要测量可见元素在可视区域内的移动情况。该指标需要重点关注,随着 Lighthouse 的版本迭代,该指标占比一直呈上升趋势,也是页面性能优化容易忽略的方面。以下为 Lighthouse 不同版本中 CLS 指标的占比情况:



•TBT


总阻塞时间(Total Blocking Time),是指测量页面被阻止响应用户输入(例如鼠标点击、屏幕点击或键盘按下)的总时间。它是通过添加 FCP 和 TTI 之间所有长任务的阻塞部分来计算总和,任何执行时间超过 50 毫秒的任务都是长任务。


各指标表现评价标准:


1.2 UEI 计算规则

UEI 指的是用户体验值,烛龙平台底层使用的是 Lighthouse 性能统计工具。其中,单页面的得分统计规则与其保持一致(性能指标分数的加权平均值)。针对多页面应用,整体评分计算规则为,每个页面得分的加权平均值:(页面 A * A 访问量 + 页面 B * B 访问量 ...)/ (A 访问量 + B 访问量 + ...)。

2、Chrome 调试工具

Chrome 的 Performance 面板,可以记录页面加载时\运行时的所有活动,方便我们找出页面的性能瓶颈。



以上为 performance 面板的概览图,通过对页面加载过程的录制,查看视图面板的主线程工作过程,我们能够找到页面阻塞的长任务,从而优化 TBT 指标;交互阶段存在的动画卡顿等问题,也可以通过该面板进行分析和优化。

三、实战

1、项目介绍

商智 C 店,是依托移动低码搭建的面向 B 端商家的应用。根据烛龙数据统计,优化之前,用户体验值在 58 分左右。我们期待通过本次优化,将烛龙统计得分提升到体验良好的水平(75 分及以上)。从下图可以看出,页面的 CLS、TBT 分数很低,LCP 指标分数位于性能良好与性能较差之间,这三个指标是我们接下来进行优化的重点。


2、过程记录

2.1 减小资源体积

2.1.1 抽取公共依赖


商智 C 店采用了主应用加三个微应用的架构,这三个微应用的包大小为:



可以发现,每个包的体积都很大(5000k 以上),这势必会影响资源下载速度并拖慢代码执行效率。微应用包体积过大的原因是:主应用和多个微应用间存在重复打包,如组件库(自研)、公共库依赖(react、react-dom、echarts)等内容。


针对该问题,可在制品的生成阶段做处理:生成两个包,一为完整的包,保证其能够独立使用;二为优化的包,里面剔除了公共依赖及组件库的样式。调整后,包的体积减少 1300 多 k,总包大小减少至 4000k 左右。



需要说明的是,自研组件库目前并没有提供 UMD 格式打包方式,因此以上提到的公共依赖不包含自研组件库相关的包(后续会处理)。


2.1.2 tree shaking 优化


tree shaking(摇树) ,用于描述移除 JavaScript 上下文中的未引用代码(dead-code)。最初起源于 ES2015 模块打包工具 rollup。


自研组件库主要包含三个包,PC 组件库 jmtd、移动组件库 jmtm、jmtd-hooks 库。其中 hooks 库是对两端组件库的二次封装,帮助低码平台处理组件间的逻辑编排功能,三个库均通过 npm 包的方式引入。



排除公共依赖及样式后,微应用制品的体积大约在 4000k 左右,这显然还不是一个理想值。打包构建工具依赖 webpack5,根据 webpack 性能分析插件分析,定位到 jmtd-hooks 包的体积过大。按照固有思维,webpack5 在生产环境默认支持 tree shaking,因此生成的制品只会打包使用到的代码,并不会引起制品的体积过大。那么问题出在哪里呢?



原因在于,jmtd-hooks 库的打包方式有问题。因 hooks 包较强的业务属性,我们将原始文件打包成了一个文件。


webpack 的 tree shaking 有两种方式:


•usedExports:开启该配置后,能够在打包环节找到未被使用且无副作用的函数且不会对其打包。 它只针对单文件生效,不能跨文件进行分析。而 js 是一门动态语言,因其灵活多变的特性,编译工具很难准确分析某个函数是否具有副作用,因此其优化能力较弱。


•sideEffects:具有跨文件分析能力,如果某个库的 package.json 中配置了 sideEffects 为 true,表明该库中的所有文件都没有副作用。若某文件中的方法未被使用,编译工具可放心的进行摇树,其优化能力更强。


分析后可得出结论:webpack 对单文件,仅利用其静态分析能力摇树效果很弱,导致微应用制品包含了大量未使用的代码。解决办法也很简单,调整 jmtd-hooks 的打包方式,保留原始的文件结构。调整后 hooks 包的结构为:



可看到,制品体积有了大幅的减小,最终控制在 2000k 以下。经过抽取公共依赖和摇树优化两个步骤,整体包体积减少**65%**左右。



2.1.3 删除项目冗余代码


随着需求持续迭代,项目中很容易存在一些无效的脚本及样式引用,或者一些不规范的写法,如未使用的全局变量、没有意义的 console 等,都需要进行删除,保持代码的精简性。


完成以上步骤后,我们进行了一次上线,并连续监测了一周的数据。用户体验值有了明显的提升,从以前的 58 分提升到 65 分


优化前:



优化后:



以下为优化前后各指标的对比数据(单位:ms):


2.2 优化资源加载速度

一个页面从输入 URL 到最后在浏览器的渲染流程大致如下:


URL 解析 => DNS 解析 => 建立 TCP 连接 => 客户端发送请求 => 服务器处理和响应请求 => 浏览器解析并渲染响应内容 => 断开 TCP 链接


从 URL 解析到服务器响应请求的过程属于网络层面,常用的优化手段包括:


1、缓存技术:合理的使用缓存,如 CDN 缓存、浏览器缓存等,来加快资源的下载速度。


2、文件压缩合并:通过压缩工具减少资源大小,多个文件合并成一个文件,减少网络请求开销。


3、开启 gzip 压缩:在文件传输阶段,开启 gzip 压缩,减小数据传输量,节省服务器网络带宽。


4、http2 协议:该协议带来了很多新的特性,如二进制分帧、头部压缩等,把证文件传输更加安全高效。


5、DNS 预解析:初次请求某个跨域域名,需先解析该域名,其解析时间很容易被忽视,DNS 预解析能够减少用户等待的时间。


6、域名分片:域名分片指的是将同一站点下的静态资源分布在不同域名下,其最大的好处是,能够突破浏览器下载资源的并发限制。


7、代码分割:将整个应用代码合理分割成多个部分,能够有效减小首屏资源的请求体积,提升资源下载速度。


2.2.1 代码分割


合理的分割代码,能够有效加快首屏资源请求速度。出于此考虑,我们将项目结构分为了一个主应用加三个微应用的模式,主应用作为基座来处理导航及微应用间通信,三个微应用(经营分析、行业竞争、我的关注)作为独立模块,承接细分的业务功能。以模块划分代码,大体上解决了问题,但针对某些高频使用的详情页,还有进一步优化的空间。



根据埋点数据统计,用户高频使用的主要有两个页面:经营分析页和指标详情页,其访问的 PV 值占到了 90%以上。经营分析页的表现尚可,用户体验值在 70 分左右,可暂不优化;指标详情页的表现堪称灾难,仅得到 58 分,明显低于现阶段 65 分的平均值。



分析原因:指标详情页为一个二级路由页面,可通过核心指标页下钻到该页,也可通过客户端首页直接查看某个指标的详情页。这将导致,在查看该页面前,需先加载经营分析模块。


解决思路:将指标详情页独立为一个微应用,单独维护。当用户通过京麦客户端直接访问某个指标的详情时(用户使用此场景频率很高),只加载该微应用代码,避免一级路由页代码的影响。


优化后效果很明显,指标详情页得分从 58 分直接飙升到 80 分,各个维度的指标都有了不错的提升。



2.2.2 资源预加载


资源预加载是性能优化的常用手段,针对模块较多的应用尤其有效。前文我们已将商智 C 店分割为主应用加三个微应用的代码结构,首页加载的是主应用加经营分析模块,当用户切换其它的模块(竞争分析、我的关注等),需要先下载该模块的制品(2000k 左右),再进行内容的渲染。


采用资源预加载方案,可在首页内容加载完成后,利用浏览器的空余资源,预加载其它模块的文件,当用户切换到其它模块时,资源已经提前加载完毕,省去资源下载的时间。


具体实现逻辑为:


// 通过动态创建script的方式,预加载文件// 脚本加载并解析完成后,会将执行逻辑挂载到全局变量上function loadScript (url) {    if (!cache || cache[url]) return;    cache[url] = new Promise(resolve => {        const script = document.createElement('script');        script.src = url;        script.onload = () => {            document.body.removeChild(script);            resolve(window.__microApp__);        };        document.body.appendChild(script);    });}
// 当页面加载完成后,通过requestIdleCallback方法,利用浏览器空余资源来预加载文件window.onload = function () { requestIdleCallback(() => { microAppArr.forEach(({ src }) => loadScript(src)); });};
复制代码


资源预加载之前,行业竞争模块的得分在 60 分,优化之后,提升到了 68 分



优化之前,我的关注模块的得分在 65 分,优化之后提升到 72 分



2.2.3 DNS 预解析


当你的网站第一次请求某个跨域域名时,需要先解析该域名(例如页面访问 cdn 资源,第一次访问需要先解析 cdn),而在该请求之后的请求都没有这项时间支出。典型的一次 DNS 解析需耗费 20-120 毫秒,其解析的时间很容易被忽视。DNS Prefetching 是具有此属性的域名,不需要用户点击链接就在后台解析,这个方式能减少用户的等待时间,提升用户体验。


<!-- 用meta信息来告知浏览器, 当前页面要做DNS预解析 --><meta http-equiv="x-dns-prefetch-control" content="on" /><!-- 在页面header中使用link标签来强制对DNS预解析 --><link rel="dns-prefetch" href="xxx.com"> 
复制代码


商智 C 店具体应用案例:



2.2.4 域名分片


域名分片指的是将同一站点下的静态资源分布在不同域名下。例如:主站域名 www.a.com;图片域名 www.a-img.com;脚本、样式等文件的域名 www.a-link.com。其最大的好处是,能够突破浏览器下载资源的并发限制,具体可参考文章


同样在商智 C 店中,我们也应用了该思路,如将 React、Echarts 等公共库、业务打包代码、图片等静态资源分别放在不同的 CDN 域名,从而突破浏览器的并发请求限制。


2.2.4 雪碧图


主应用的底部是一个菜单导航,它的图标包含了 6 张图片(选中和非选中态使用不同图片),一个合理的方式是,使用雪碧图(Sprite),将多个连续的图片合并为一张,通过改变背景图位置来控制图片显示。


2.3 优化用户感知

2.3.1 滚动加载


微应用模块的展示形式为橱窗卡片组成的长列表(10 个左右,后续需求迭代还会增加)。橱窗卡片作为基础的布局组件,承接了筛选区域、下钻功能、可视化组件的展示功能,如果在首屏一次加载太多,将会导致较大的渲染压力。



滚动加载是提升首屏渲染性能的很好方案,它的核心是判断目标元素(橱窗卡片)是否在可视区域范围内,当其不可见时,只需在卡片内容区渲染一个有默认高度的占位元素,同时也不必加载筛选区域组件,当用户滚动到该区域时,再渲染业务相关的内容。



如图所示,首屏只需渲染核心指标和目标监控两个橱窗卡片的内容,其余卡片只渲染一个占位元素,有效缓解浏览器的渲染压力。那么具体逻辑是怎么实现的呢?


通常有两种方式可判断元素是否在可视范围内:


1、监听 scroll 事件,获取目标元素(橱窗卡片)相对于视口的坐标,再判断其是否在可视区域内。该方法的缺点是,scroll 事件密集触发,容易造成性能问题。


2、IntersectionObserver API,翻译为”交叉观察器“,可以自动"观察"元素是否可见,Chrome 51+ 支持。


这里我们采用第二种方案,初始状态设置内容区域不可见,当元素挂载完成后,创建 io 监听器,监听到卡片位于可视范围内,再加载对应组件,具体逻辑参考以下代码。


function WindowCard ({ title, filter, children }) {    const wcRef = useRef(null);    // 初始状态,默认设置内容区域不可见    const [visible, setVisible] = useState(!useObserver);    useEffect(() => {        // 元素挂载后,创建io监听器        const io = new IntersectionObserver(entries => {            if (entries[0].intersectionRatio <= 0) return;            // 当元素位于可视区域范围内后,加载业务组件            setVisible(true);            // 业务组件加载后,断开监听            io.unobserve(wcRef.current);        });        io.observe(wcRef.current);
return () => { io.disconnect(); }; }, []);
return ( <div className='window-card' ref={wcRef}> // 省略head部分逻辑 <div className='window-card-content'> {visible ? children : <div style={{ height: 200 }} />} </div> </div> );}
复制代码


2.3.2 优化 CLS 指标


根据 LightHouse 统计数据,CLS 指标得分值很低,其反映了在首屏页面加载时,出现了较大的布局偏移。


类似于核心指标卡片,在指标卡加载前,内容区域高度为 0,而 loading 加载后,有一个 200px 的占位高度,真实的指标卡渲染出来后,高度变为 322px,用户能够感觉到明显的抖动。



还有指标详情页中的场景,在指标卡 loading 阶段,占位高度为 200px,而真实渲染的指标卡的高度为 142px。假如用户在此时点击某个可点击区域,很容以造成误触,带来很差的用户体验。



诸如以上的场景,我们事先能够确定指标卡渲染出来的真实高度,可以提前将其固定。参照类似的方法,检查其他的页面,能够尽量避免页面首屏的抖动。

3、实战总结

通过抽取公共依赖和摇树优化,微应用的体积从 5000 多 k 减小到 2000k 以内,应用体验值从 58 分提升到 65 分。通过对长列表页面适配滚动加载,提升了页面的渲染效率;固定首屏指标卡等元素的高度,减少了页面布局偏移,从而保证页面稳定的显示效果;将用户高频使用页面(指标详情页)独立为微应用,直接将拖后腿的页面变成性能表现优秀的页面;资源预加载,充分利用了浏览器的空余资源,有效提高页面加载速度。应用的体验值,从 65 分提升到 75 分:


优化前:



优化后:



细分指标的表现都有了明显提升,以下为优化前后的对比数据:



本次优化的重点是提升商智 C 店首屏显示的效果,目标是将烛龙统计得分提升到体验良好的水平(75 分及以上),基本完成了预定目标。因优化过程位于需求迭代的间隙,并不计划对系统架构及业务代码进行深度调整,因此还有些遗留工作放到了后续:如微应用的体积仍有进一步优化的空间、TBT 指标得分虽有提升,但表现仍较差、某些组件交互动效卡顿等。


最后,期望本文的经验能给同样在做性能优化的小伙伴一些参考,文章的不足之处,可在评论区讨论。敬请期待后续移动端交互优化的文章。


作者:京东零售 郄鹏飞


来源:京东云开发者社区 转载请注明来源

用户头像

拥抱技术,与开发者携手创造未来! 2018-11-20 加入

我们将持续为人工智能、大数据、云计算、物联网等相关领域的开发者,提供技术干货、行业技术内容、技术落地实践等文章内容。京东云开发者社区官方网站【https://developer.jdcloud.com/】,欢迎大家来玩

评论

发布
暂无评论
商智C店H5性能优化实战_前端_京东科技开发者_InfoQ写作社区