一行可以讓 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