移動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打包速度優化，代碼封裝優化，動畫優化等方面的我的經驗，若是喜歡就點個贊吧~。

（文章原創整理，轉載請註明出處，謝~）