移动spa商城优化记（一）---首屏优化篇

背景

随着公司业务的不断壮大，最近总是有用户反应公司APP内的商城打开比较慢，这可不行啊，慢了容易流失用户，流失用户减小公司业绩，公司业绩少个人年终奖就少…………，因此为了公司，也为了本身，开始优化之路。

商城系统是去年开发的，是一个基于vue2.0的spa项目，最好的优化思路固然是与原生移动端同窗合做将它hybird化，可是这样时间周期太长，改造也太大，并且年后原生移动端的同窗也有离职的，致使人手不足，因此只能本身改造。

相关系列文章：

移动spa商城优化记（二）--- webpack打包速度优化篇

开始

这一篇是首屏优化篇，只讲首屏优化部分，先来看一下首屏彻底加载出来长啥样，

加载步骤图

首先从原生app点击底栏的商城进入H5页面，此时瞬间大概长这样，

而后通过1-2s左右的时间（无缓存状况）会看到到下面这个loading动画，

而后loading2-3s左右彻底加载出来

加载总时长在3-5s左右。

1.进入h5页以前的优化

此处白屏时间主要是移动端webview初始化以及在加载H5的静态资源，此处优化点有四个：

1.全局WebView

方法：

• 在客户端刚启动时，就初始化一个全局的WebView待用，并隐藏；

• 当用户访问了WebView时，直接使用这个WebView加载对应网页，并展现。

这种方法能够比较有效的减小WebView在App中的首次打开时间。当用户访问页面时，不须要初始化WebView的时间。

此处须要移动端同窗配合。

2.前端代码打包优化

首先，要看看首屏都加载了哪些东西，最主要就是这几个，其中app和vendor都有上百k

而后开始分析文件为何这么大，执行

npm run build --report复制代码

而后会看到一张相似这样的图（是否是很装逼~）

（图是网上找的，并无用项目的分析图，怕被总监说泄漏源码~）

而后，一看vendor.js里面有部分lodash和moment以及第三方的一些插件的包，这都是当时赶进度偷懒留的坑啊，因而能手写的所有本身手写，去掉第三方一些包的体积。而后再把一些首页用不到的包进行懒加载，再也不放到全局引用。

其余优化体积的方法如：

tree-shaking：去除没用过的代码

UglifyJsPlugin：压缩代码

ExtractTextPlugin：提取css出来

这些在以前就用过了，不在此次优化任务里面，再也不细说，能够自行查阅插件用法。

3.pwa

此处推荐一个webpack插件offline-plugin，具体用法看这篇文章：

使用offline-plugin搭配webpack轻松实现PWA

此次用pwa主要是用了它的离线缓存，和http cache缓存同样，可是相对来讲缓存更可控。

4.loading动画前移

如今只有H5的静态资源加载完毕后才会看到loading动画，H5静态资源优化的再小中间也是有白屏时间的，因此咱们在移动端加上了loading动画，而把H5的loading动画去掉换用了骨架屏，具体在下面说。

2.进入h5页以后的优化

此处h5静态资源加载完后会看到loading动画，loading动画时在作什么呢？请求A接口，A接口返回后请求B接口，B接口返回后请求………此处优化点有四个：

1.骨架屏

一进页面先加载骨架屏占位，而后再去数据填充。

咱们骨架屏是本身写的，也能够用插件

vue-skeleton-webpack-plugin

用法能够看这里：

为vue项目添加骨架屏

2.部分前端请求改成服务端内网请求

好比用户信息这类接口原本是前端请求完后拿到用户信息，再拿着用户信息去请求与用户相关的页面数据，可是有些网络不稳定的地方接口串行很容易慢，若是一个超时了还得再请求一遍，因此这类移到服务端去作，直接变成内网调用接口，不受客户端网络环境影响。

3.拆分接口，页面分批渲染，部分接口数据作localstorage缓存

以前首页的数据接口为了赶时间，全部数据都是一个接口返回的，因此后端要查好多表，此次咱们把一个接口拆分为多个接口，分批加载填充，另外商品分类等这种不太常常变化的数据前端缓存到localstorage中，一进页面先去localstorage中拿数据渲染，而后再动态更新。

先拿到不用区别用户的通用首页数据，并把能够缓存的缓存起来，下次直接用不走接口。

而后与用户有关的数据也回来了，再分批渲染上

最终优化后的结果是：

无白屏时间，原生loading动画1s后看到H5骨架屏，2s以内看到全部数据加载完成。

总体速度从原来的3-5s优化到1-2s之间，有缓存状况能够作到秒开，固然还有其余能够优化的地方，之后优化完了再补充。

首屏优化为何没用vue-ssr

有同窗评论问首屏优化为啥不用vue-ssr，实际上是该用的，可是公司由于有更重要的项目排进来了，金三银四公司人手不太够，因此先在旧的基础上进行了优化，等抽出时间会进行服务端渲染的优化，到时候改完会再次分享一篇关于spa迁移ssr的优化文章~

最后

其实性能优化没有公式，仍是要根据具体项目具体分析，每一个项目的可优化点及优化方式都不同，不能只会死板硬套雅虎军规这种公式类优化准则。

这是移动spa商城优化的第一篇，之后还会说下有关此项目的webpack打包速度优化，代码封装优化，动画优化等方面的我的经验，若是喜欢就点个赞吧~。

（文章原创整理，转载请注明出处，谢~）