一行可讓項目啓動快70%以上的代碼

前言

這兩天閒來無事，想優化優化項目的啓動時間，用了一個下午吧，將項目啓動時間從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檢查和加載耗時過長，致使項目啓動時間較久。

解決方案

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

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

解決方案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版本？

筆者立即在node_modules裏面找到了插件，而後查看了package.json文件，結果失望的發現webpack的版本是4.2.6，這就使人絕望了，難道真的不能夠麼？

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

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

哦呦，還真有點小驚喜呦，這功能簡直了，這不就是我想要的麼？而後當機立斷，往vue.config.js裏一家，您猜怎麼着？

成了！

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

重啓了幾回項目後發現啓動時間已經穩定了，效果然的還不錯呦～

直接給我幹到了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插件，具體用什麼就本身決定吧。

這裏其實仍是留了個坑，hard-source-webpack-plugin用不了的具體緣由是什麼呢？筆者只是猜想和speed-measure-webpack-plugin、webpack-bundle-analyzer這兩個插件有關，但卻不能確定，若是有讀者知道，歡迎在評論區留言或者私信筆者。

看了這麼久，辛苦了！

〈（_　_）〉

PS：筆者還一系列使用JavaScript刷題的文章，有興趣的能夠點進我的主頁看看，放兩個目錄：

這裏是按照日期分類的👇

前端刷題路-目錄（日期分類）

這裏是按照題型分類的👇

前端刷題路-目錄（題型分類）