前言

這兩天閑來無事，想優(yōu)化優(yōu)化項目的啟動時間，用了一個下午吧，將項目啟動時間從48秒優(yōu)化到14秒，大約70左右，效果還是有的，而且僅僅用了一行代碼。

👇會講一下找到這行代碼的過程，如果沒有耐心可以直接跳轉(zhuǎn)到文章底部，直接看結(jié)論即可。

項目背景

項目就是簡單的Vue項目，不過公司內(nèi)部給vue-cli包了一層，不過影響不大。

別的也就沒啥了，正常的H5網(wǎng)頁，用的插件也不算多，為了控制項目體積。

項目分析

既然決定要優(yōu)化了，首先要分析下項目，先用speed-measure-webpack-plugin和webpack-bundle-analyzer分析下，具體的配置這里就不多說了，很簡單，網(wǎng)上一搜一大堆，這里直接看看結(jié)論。

首先是項目運行時間：

可以看到，基本上耗時大戶就是eslint-loader和vue-loader了，二者一個耗時40多秒，一個耗時30多秒，非常的占用資源。

接下來再看看具體的包分析👇

這一看就很一下子定位到問題到根源了，右側(cè)的chunk-vendors不用看，只看左側(cè)的chunk-page，這里面的頁面數(shù)量太多了，相應(yīng)的文件也很多，這也就直接導(dǎo)致了eslint-loader和vue-loader耗時很久了，這么多文件，一個個檢查耗時當(dāng)然久了。

右側(cè)其實還可以繼續(xù)優(yōu)化，但感覺沒必要，swiper其實并不大。

那么現(xiàn)在就可以具體定位到問題了，由于項目是多SPA應(yīng)用，致使.vue文件眾多，在項目啟動時進行eslint檢查和加載耗時過長，導(dǎo)致項目啟動時間較久。

解決方案

找到問題之后就得解決問題了，初步的解決方案有兩個：

1.  干掉eslint，在本地編譯時不檢查
2.  緩存

解決方案1必然是最簡單的，但其實有點不合理，開著eslint就是為了規(guī)范代碼格式，雖然在提交代碼時也有對應(yīng)的鉤子來格式化代碼，但在開發(fā)過程中進行提示可以更好的幫助我們形成合理的編碼方式。

所以現(xiàn)在剩下的方案就只有進行緩存操作了，接下來筆者就開始找相關(guān)插件來更好的進行緩存了。

嘗試解決

首先是hard-source-webpack-plugin，這插件為模塊提供中間緩存步驟，但項目得跑兩次，第一次構(gòu)建時間正常，第二次大概能省去90%左右的時間。

這插件很多文章都有推薦，感覺很不錯的樣子，用起來也很簡單，只需要👇： 

plugins: [  
  new HardSourceWebpackPlugin()  
] 

這就完事了。

就這么簡單？確實是這么簡單，但也不簡單，如果到此為止，筆者也不會折騰一下午了。

就這么簡單的一安裝： 

npm i hard-source-webpack-plugin -D 

然后像👆一樣簡單的配置，然后重啟項目，您猜怎么著？

報錯了！

原因是什么呢？

是因為speed-measure-webpack-plugin或者webpack-bundle-analyzer中的某一個，為什么呢？

原因筆者其實并不太清楚，因為啟動的時候報的錯是這樣的：

Cannot find module 'webpack/lib/DependenciesBlockVariable'

哦呦，這個錯有點小意外，怎么會突然報webpack的錯呢？

筆者也是百思不得其解啊，去Google也沒有人遇到這種問題。

不得已，只能去hard-source-webpack-plugin的github上看issue，發(fā)現(xiàn)其實有人遇到這個問題的，他們的解決方案就是降低webpack的版本，可筆者這里沒辦法這么做，因為都集成在vue-cli里了，而且這個還是公司內(nèi)部包了一層的，這就根本不可能降版本了。

第一個轉(zhuǎn)機

那還能怎么辦呢？

實在沒有辦法了，筆者嘗試搜索DependenciesBlockVariable的相關(guān)內(nèi)容，這時事情發(fā)生了一絲微妙的變換，原來這個功能在webpack5中被移除了，難道是因為公司內(nèi)部的vue-cli用的是webpack5.x版本？

img

筆者當(dāng)即在node_modules里面找到了插件，然后查看了package.json文件，結(jié)果失望的發(fā)現(xiàn)webpack的版本是4.2.6，這就令人絕望了，難道真的不可以么？

既然打開了webpack的文檔，那就好好看看吧。老實說這文檔筆者已經(jīng)看了N次了，真是每次看都有小驚喜，功能真是太多了。

翻著翻著就看到了這個小功能👇：

哦呦，還真有點小驚喜呦，這功能簡直了，這不就是我想要的么？然后當(dāng)機立斷，往vue.config.js里一家，您猜怎么著？

成了！

雖然文檔是webpack5.0的，但筆者發(fā)現(xiàn)4.x版本中也有這個功能，可能若一弱一些吧，多少能用啊。

重啟了幾次項目后發(fā)現(xiàn)啟動時間已經(jīng)穩(wěn)定了，效果真的還不錯呦～

img

直接給我干到了14秒，雖然有些不太穩(wěn)定，但這已經(jīng)是當(dāng)前狀態(tài)的最好解決方案了。

所以最后的代碼就是： 

chainWebpack: (config) => {  
  config.cache(true)  
} 

用chainWebpack的原因是項目中其實沒有獨立的webpack.config.js文件，所以只能放在vue.config.js文件中，使用chainWebpack來將配置插入到webpack中去。

你以為事情到這里就結(jié)束了么？太簡單了。

第二個轉(zhuǎn)機

解決完問題后，當(dāng)然要把speed-measure-webpack-plugin和webpack-bundle-analyzer這兩個插件刪掉了，然后整理整理代碼，推上去完事。

可筆者還是不死心，為啥hard-source-webpack-plugin不好使呢？不應(yīng)該啊，為啥別人都能用，自己的項目卻用不了呢？

為了再次操作一手，也是為了更好的優(yōu)化項目的啟動時間，筆者再次安裝了hard-source-webpack-plugin，并且對其進行了配置： 

chainWebpack: (config) => {  
  config.plugin('cache').use(HardSourceWebpackPlugin)  
} 

這次再一跑，您猜怎么著？

成了！

為了避免再次啟動失敗了，筆者這次沒有使用speed-measure-webpack-plugin和webpack-bundle-analyzer這兩個插件，所以啟動時間也沒法具體估計了，但目測時間再10秒以內(nèi)，強啊。

所以說hard-source-webpack-plugin失敗的原因可能就是那兩個統(tǒng)計插件的原因了，得虧再試了一次，要不然就不明不白的GG了。

結(jié)論

這里的結(jié)論就很簡單了，有兩個版本。

首先，如果項目能使用hard-source-webpack-plugin就很方便了，用就完事了，啥事也不需要干，所以這一行代碼是👇： 

config.plugin('cache').use(HardSourceWebpackPlugin) 

大概真能快90%以上，官方并沒有虛報時間。

其次，如果用不了hard-source-webpack-plugin那就放棄吧，嘗試webpack自帶的cache功能也是不錯的，雖然比不上hard-source-webpack-plugin，但多少也能提升70%左右的啟動時間，所以這一行代碼是👇： 

config.cache(true)  
復(fù)制代碼 

并且不需要安裝任何插件，一步到位。

這兩種方法其實都是可行了，論穩(wěn)定和效果的話hard-source-webpack-plugin還是更勝一籌，但cache勝在不用裝額外的webpack插件，具體用什么就自己決定吧。