入職一周後，上一個前端就離職了（超級坑爹的），留下了一個比較棘手的問題，就是基於vue-cli的項目打包超級慢，我接手項目的時候，打包需要45min（上個離職者也不知道原因），經過3個月之後，隨著項目的不斷叠代，打包的時間飆升到了2個半小時。為了解決這個問題，以前沒有做過這方面的優化，在結合網上的一些優化博客，就開啟了以下的優化之路。

一、懷疑vue-cli打包配置文件被修改過（不行）

　　基於此點的懷疑，使用vue-cli重新搭建環境。

　　步驟一：vue init webpack 項目名稱。

　　步驟二：把以前的代碼一步步移植到新的開發環境，期間發現以前的代碼很多不符合eslint規則的代碼，需要一步步的修改，超級無語。

　　步驟三：npm run build --report，發現打包時間依舊沒有下降，還是2個半小時，瞬間淚奔。打包分析如下圖。

　　步驟四：此懷疑可以跳過了。

二、經過第一步，發現有一些打包的文件非常大，如Element UI沒有按需加載，cityData.js等都是非常大的，由此懷疑是不是該問題導致打包時間長（不行）

　　步驟一：按需加載Element UI組件，具體可以參考我之前寫過的文章。傳送門

　　步驟二：查看cityData.js的內容，發現是一些省市區的數據，前期的數據都是通過這個文件來獲取省市區數據，後來改為通過後臺獲取的了，上個離職人員忘記把代碼註釋掉了

　　步驟三：npm run build --report，發現打包時間依舊沒有下降，還是2個半小時，瞬間淚奔。打包分析如下圖。確實打包的體積小了一點，算是有一點優化了吧。。。

　　步驟四：此懷疑可以去掉了。

三、結合網上的優化方式，進行了以下的優化方式，效果都不是不好。（不行）

　　方式1：不生成.map文件，修改config/index.js文件中的productionSourceMap屬性值為false

　　方式2：resolve.alias 配置路徑別名

　　方式3：babel-loader優化，排除node_modules模塊，準確獲取src的目錄，並且開啟緩存

　　方式4：使用webpack-parallel-uglify-plugin多線程壓縮JS

　　方式5：使用HappyPack多進程進行loader處理

　　上述5中方式都可以參考該博文進行配置，傳送門

四、使用DllPlugin和DllReferencePlugin處理，效果很明顯，由原來的2個半小時變為了3分鐘 （該方法可行）

　　這是參考的博文，不再贅述了。傳送門

五、在完成第四步之後，以為優化已經完成了，準備收工的時候，突然想到了該項目的router在開發環境的時候不進行路由懶加載，在打包生產包的時候使用路由懶加載的，會不會是該問題導致的呢？

所以重新改寫了router/index.js文件的懶加載方式，無論是開發環境還是生產環境都是使用懶加載方式。

　　原來的加載路由的方式：

　　_import_development.js文件：本地開發的時候，不使用懶加載的方式，而是使用Common.js的方式直接引入，這樣熱加載就會很快完成的。

　　_import_production.js文件：

　　修改之後，不使用_import_development.js和_import_production.js文件，而是直接在router/index.js中直接使用 () => import(‘@/components/xxx‘)進行路由懶加載。

在重新打包的時候，發現竟然只要1分鐘左右就完成了打包任務，但是本地開發的時候，熱加載的時間由原來的5s變為了22s。坑爹的，因小失大啊。

六、結論

　　拋棄原來的路由加載方式，使用第五步的路由懶加載方式只會，可以結合第二步、第三步、第四步進行打包優化，這樣也會加快打包速度以及減少打包體積。

基於vue-cli項目打包慢的定位優化過程