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

作者:rexkentzheng

https://juejin.cn/post/6961203055257714702

前言

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

👇會講一下找到這行代碼的過程,如果沒有耐心可以直接跳轉到文章底部,直接看結論即可。

項目背景

項目就是簡單的 Vue 項目,不過公司內部給vue-cli包了一層,不過影響不大。

別的也就沒啥了,正常的 H5 網頁,用的插件也不算多,爲了控制項目體積。

項目分析

既然決定要優化了,首先要分析下項目,先用speed-measure-webpack-pluginwebpack-bundle-analyzer分析下,具體的配置這裏就不多說了,很簡單,網上一搜一大堆,這裏直接看看結論。

首先是項目運行時間:

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

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

這一看就很一下子定位到問題到根源了,右側的 chunk-vendors 不用看,只看左側的 chunk-page,這裏面的頁面數量太多了,相應的文件也很多,這也就直接導致了eslint-loadervue-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 版本?

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