项目中的性能优化实战

项目背景：使用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之内的速度。

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