背景
隨著公司業務的不斷壯大，最近老是有使用者反應公司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
用法可以看這裡：
2.部分前端請求改為服務端內網請求
比如使用者資訊這類介面本來是前端請求完後拿到使用者資訊，再拿著使用者資訊去請求與使用者相關的頁面資料，但是有些網路不穩定的地方介面序列很容易慢，如果一個超時了還得再請求一遍，所以這類移到服務端去做，直接變成內網呼叫介面，不受客戶端網路環境影響。
3.拆分介面，頁面分批渲染，部分介面資料做localstorage快取
之前首頁的資料介面為了趕時間，所有資料都是一個介面返回的，所以後端要查好多表，這次我們把一個介面拆分為多個介面，分批載入填充，另外商品分類等這種不太經常變化的資料前端快取到localstorage中，一進頁面先去localstorage中拿資料渲染，然後再動態更新。
先拿到不用區別使用者的通用首頁資料，並把可以快取的快取起來，下次直接用不走介面。
然後與使用者有關的資料也回來了，再分批渲染上
最終優化後的結果是：
無白屏時間，原生loading動畫1s後看到H5骨架屏，2s之內看到所有資料載入完成。
整體速度從原來的3-5s優化到1-2s之間，有快取情況可以做到秒開，當然還有其他可以優化的地方，以後優化完了再補充。
首屏優化為什麼沒用vue-ssr
有同學評論問首屏優化為啥不用vue-ssr，其實是該用的，但是公司因為有更重要的專案排進來了，金三銀四公司人手不太夠，所以先在舊的基礎上進行了優化，等抽出時間會進行服務端渲染的優化，到時候改完會再次分享一篇關於spa遷移ssr的優化文章~
最後
其實效能優化沒有公式，還是要根據具體專案具體分析，每個專案的可優化點及優化方式都不一樣，不能只會死板硬套雅虎軍規這種公式類優化準則。
這是移動spa商城優化的第一篇，以後還會說下有關此專案的webpack打包速度優化，程式碼封裝優化，動畫優化等方面的個人經驗，如果喜歡就點個贊吧~。
（文章原創整理，轉載請註明出處，謝~）