项目中的性能优化实战

项目背景:使用nuxt.js构建的一个服务端渲染项目

第一轮优化工作:

 

banner图的懒加载:

为什么要做?

减少首屏打开时的资源请求数量,提高资源加载速度。

过程分析:如果使用swiper自带的懒加载轮播切换会有闪烁,体验不好,如果swiper和lazyload同时使用,轮播一圈后第一张显示空白

最后解决方案是:首尾两张图片不用懒加载。

 

学员案例懒加载:

(该模块是由一个横向可滑动的多图形式构成的)

为什么要做?

减少首屏打开时的资源请求数量,提高资源加载速度。

过程分析:通过direction和yoga_o2_session_model_style_id两个字段确定学员案例模块,并添加对应的ref标识

 

 banner和学员案例都是横向滑动的图片,服务器返回的图片宽高比未知,所以需要动态获取到图片的高度之后,再设定懒加载的默认图高度,否则样式展示会有问题。

 

结果验证:请求数量(同一课程):

改动前:53次

 

改动后:30次

 

资源加载时间:

修改前:

 

修改后:

 

需要继续跟进的事情:

这里资源加载的时间虽然变短了,但是管理后台记录的dom ready时间并没有多大变化,思考应该是因为dom ready的时间计算是由js下载并执行完所得,图片懒加载只是减少了图片的资源请求数量,对于js资源影响不大,接下来准备对项目中的第三方库swiper进行替换,减小js包体大小。

dns预解析:

为什么要做?

dns预解析主要是为了减小dns查询时间 

实现过程:

通过nuxt.config.js的配置添加dns预解析

 

结果验证:

修改前:

修改后:

 

结果分析:对dns查询时间无明显效果,暂时还不知道原因,需继续跟进。



第二轮优化工作:

swiper组件替换:

为什么要做?

第三方swiper库功能确实很强大,但是包体较大,gzip压缩后大概32k左右

项目中的轮播图只是用到了swiper库中很小的一个组件,考虑剔除swiper库,自己封装一个swiper组件,可以减小js包体大小,提升加载速度。

过程分析:

主要用到的技术点就是 touchstart  touchmove  touchend三个手指事件。

这三个事件都有个共同的api可以拿到当前手指滑动的位置,event.changedTouches[0].pageX。这样子剩下的交互基本上全部可以通过手指的位置来做判断。具体的代码逻辑就不在这贴出来了。

阿里监控代码改为cdn异步引入:

为什么要做?

之前训练营这块阿里监控代码是通过npm包引入的,这样的引入方式会在项目打包时将该npm包一起打到项目代码中,该包体大小gzip压缩后13k左右,所以考虑换成cdn引入,剔除该npm包,减少项目包体大小,提高资源加载速度。

 

过程分析:

查看阿里官方文档,发现是有cdn方式异步引入的示例代码的,如下

 

但是这段代码中使用了with方法,由于该方法的种种弊端(https://blog.csdn.net/zwkkkk1/article/details/79725934 ),所以代码中一般是不推荐使用的。在严格模式下,该段代码会报错,所以这块需要手动修改一下代码的书写,如下:

 

神策sdk从npm包引入改为本地引入:

为什么要做?

nuxt在打包时,针对入口index.vue文件打包会区分 第三方库  和  业务代码,也就是说会将index.vue文件打包成两个js文件,前面将swiper组件剔除后,index.vue文件中剩余的第三方库就是神策的sdk了,所以将神策的sdk引入方式改为本地引入,这样打包可以减少一个vender.js文件

过程分析:

从神策github中找到sensorsdata.min.js文件,放到项目中,通过nuxt.config.js配置在plugin配置项中,该js会在window下暴露一个 sensorsDataAnalytic201505 的全局对象,可直接全局使用。

       

 

优化前后数据对比:

资源加载:

优化前:

进入页面后加载7个js文件,各个js文件大小如图,总大小157kb左右。

优化后:

页面打开加载5个js文件(bl.js为阿里监控异步引入代码,理论上对资源加载没啥影响),各个js文件大小如图,总大小105kb左右。

线上数据:

可以看到上线后,访问速度有明显提升,基本稳定在1s之内的速度。

总结:减少不必要的代码,缩小打包后的静态资源文件大小才是硬道理。

 

 

猜你喜欢

转载自blog.csdn.net/longgege001/article/details/116757887