一行可以讓 VUE 項目啓動快 70- 以上的代碼
作者：rexkentzheng
https://juejin.cn/post/6961203055257714702
前言
這兩天閒來無事，想優化優化項目的啓動時間，用了一個下午吧，將項目啓動時間從 48 秒優化到 14 秒，大約 70 左右，效果還是有的，而且僅僅用了一行代碼。
👇會講一下找到這行代碼的過程，如果沒有耐心可以直接跳轉到文章底部，直接看結論即可。
項目背景
項目就是簡單的 Vue 項目，不過公司內部給vue-cli包了一層，不過影響不大。
別的也就沒啥了，正常的 H5 網頁，用的插件也不算多，爲了控制項目體積。
項目分析
既然決定要優化了，首先要分析下項目，先用speed-measure-webpack-plugin和webpack-bundle-analyzer分析下，具體的配置這裏就不多說了，很簡單，網上一搜一大堆，這裏直接看看結論。
首先是項目運行時間：
可以看到，基本上耗時大戶就是eslint-loader和vue-loader了，二者一個耗時 40 多秒，一個耗時 30 多秒，非常的佔用資源。
接下來再看看具體的包分析👇
這一看就很一下子定位到問題到根源了，右側的 chunk-vendors 不用看，只看左側的 chunk-page，這裏面的頁面數量太多了，相應的文件也很多，這也就直接導致了eslint-loader和vue-loader耗時很久了，這麼多文件，一個個檢查耗時當然久了。
右側其實還可以繼續優化，但感覺沒必要，swiper其實並不大。
那麼現在就可以具體定位到問題了，由於項目是多 SPA 應用，致使.vue文件衆多，在項目啓動時進行eslint檢查和加載耗時過長，導致項目啓動時間較久。
解決方案
找到問題之後就得解決問題了，初步的解決方案有兩個：
-
幹掉
eslint，在本地編譯時不檢查 -
緩存
解決方案 1 必然是最簡單的，但其實有點不合理，開着eslint就是爲了規範代碼格式，雖然在提交代碼時也有對應的鉤子來格式化代碼，但在開發過程中進行提示可以更好的幫助我們形成合理的編碼方式。
所以現在剩下的方案就只有進行緩存操作了，接下來筆者就開始找相關插件來更好的進行緩存了。
嘗試解決
首先是 hard-source-webpack-plugin，這插件爲模塊提供中間緩存步驟，但項目得跑兩次，第一次構建時間正常，第二次大概能省去 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，發現其實有人遇到這個問題的，他們的解決方案就是降低webpack的版本，可筆者這裏沒辦法這麼做，因爲都集成在vue-cli裏了，而且這個還是公司內部包了一層的，這就根本不可能降版本了。
第一個轉機
那還能怎麼辦呢？
實在沒有辦法了，筆者嘗試搜索 DependenciesBlockVariable 的相關內容，這時事情發生了一絲微妙的變換，原來這個功能在webpack5中被移除了，難道是因爲公司內部的vue-cli用的是 webpack5.x 版本？
img
筆者當即在 node_modules 裏面找到了插件，然後查看了 package.json 文件，結果失望的發現 webpack 的版本是 4.2.6，這就令人絕望了，難道真的不可以麼？
既然打開了 webpack 的文檔，那就好好看看吧。老實說這文檔筆者已經看了 N 次了，真是每次看都有小驚喜，功能真是太多了。
翻着翻着就看到了這個小功能👇：
哦呦，還真有點小驚喜呦，這功能簡直了，這不就是我想要的麼？然後當機立斷，往 vue.config.js 裏一家，您猜怎麼着？
成了！
雖然文檔是 webpack5.0 的，但筆者發現 4.x 版本中也有這個功能，可能若一弱一些吧，多少能用啊。
重啓了幾次項目後發現啓動時間已經穩定了，效果真的還不錯呦～
img
直接給我幹到了 14 秒，雖然有些不太穩定，但這已經是當前狀態的最好解決方案了。
所以最後的代碼就是：
chainWebpack: (config) => {
config.cache(true)
}用chainWebpack的原因是項目中其實沒有獨立的 webpack.config.js 文件，所以只能放在 vue.config.js 文件中，使用chainWebpack來將配置插入到 webpack 中去。
你以爲事情到這裏就結束了麼？太簡單了。
第二個轉機
解決完問題後，當然要把 speed-measure-webpack-plugin 和 webpack-bundle-analyzer 這兩個插件刪掉了，然後整理整理代碼，推上去完事。
可筆者還是不死心，爲啥 hard-source-webpack-plugin 不好使呢？不應該啊，爲啥別人都能用，自己的項目卻用不了呢？
爲了再次操作一手，也是爲了更好的優化項目的啓動時間，筆者再次安裝了 hard-source-webpack-plugin，並且對其進行了配置：
chainWebpack: (config) => {
config.plugin('cache').use(HardSourceWebpackPlugin)
}這次再一跑，您猜怎麼着？
成了！
爲了避免再次啓動失敗了，筆者這次沒有使用 speed-measure-webpack-plugin 和 webpack-bundle-analyzer 這兩個插件，所以啓動時間也沒法具體估計了，但目測時間再 10 秒以內，強啊。
所以說 hard-source-webpack-plugin 失敗的原因可能就是那兩個統計插件的原因了，得虧再試了一次，要不然就不明不白的 GG 了。
結論
這裏的結論就很簡單了，有兩個版本。
首先，如果項目能使用 hard-source-webpack-plugin 就很方便了，用就完事了，啥事也不需要幹，所以這一行代碼是👇：
config.plugin('cache').use(HardSourceWebpackPlugin)大概真能快 90% 以上，官方並沒有虛報時間。
其次，如果用不了 hard-source-webpack-plugin 那就放棄吧，嘗試 webpack 自帶的cache功能也是不錯的，雖然比不上 hard-source-webpack-plugin，但多少也能提升 70% 左右的啓動時間，所以這一行代碼是👇：
config.cache(true)
複製代碼並且不需要安裝任何插件，一步到位。
這兩種方法其實都是可行了，論穩定和效果的話 hard-source-webpack-plugin 還是更勝一籌，但cache勝在不用裝額外的 webpack 插件，具體用什麼就自己決定吧。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/HIeEql7EpKZxabQ2gnxH-A