起因

在公司搭建了套webpack多頁面應(yīng)用腳手架，開始用著很爽，解決了既想使用Vue的模塊化開發(fā)，又想做多頁打包上線管理的初衷，但是隨著業(yè)務(wù)項(xiàng)目的增加，我發(fā)現(xiàn)npm run dev的時(shí)候，每次熱加載，webpack的反應(yīng)都很慢。

基本會卡在

94% assets optimization95% emitting

這個(gè)步驟很久

準(zhǔn)備具體定位一下問題的原因。由于項(xiàng)目基于vue-cli改寫的多頁應(yīng)用腳手架，手動(dòng)重寫了HtmlWebpackPlugin插件，所以基本猜測和這個(gè)有關(guān)，后來證明也真的是這個(gè)引起的。

我們可以在package.json中啟動(dòng)dev的時(shí)候添加--profile命令，去看啟動(dòng)的詳情。

我們可以看到，asset optimization過程耗時(shí)2s左右，有時(shí)候會更長，所以基本確定就是這個(gè)地方卡住了HMR。

那么問題來了，怎么優(yōu)化這里？

優(yōu)化思路-1

第一想法是，在dev的時(shí)候，加入?yún)?shù)或手動(dòng)更改config，只針對當(dāng)前開發(fā)的項(xiàng)目進(jìn)行模塊的加載。

更改webpack配置是比較直接的方案，比如把當(dāng)前啟動(dòng)的目錄配置好(buildingPage), new HtmlWEbpackPlugin的時(shí)候進(jìn)行判斷即可。

第二個(gè)方案，當(dāng)然也可以手寫webpack-dev-server。

dev-server這個(gè)在老版本是在build目錄下面的，比較方便改動(dòng)重寫，然而新的版本，是在node_modules中的已經(jīng)加載的模塊，

重寫的話需要自己把這個(gè)東東搞一套，加入?yún)?shù)進(jìn)行判斷處理，本人還沒有時(shí)間進(jìn)行嘗試，如果有人有時(shí)間的可以試試能否改善HMR效率。

實(shí)踐證明第一個(gè)方案確實(shí)會提高HMR速度，但由于項(xiàng)目是多人共同開發(fā)和維護(hù)，每個(gè)開發(fā)者更改自己的config配置，極容易造成提交svn\git沖突，或忘記修改config等狀況，所以除了個(gè)人維護(hù)的項(xiàng)目，并不建議這么做。

優(yōu)化思路-2

其實(shí)這個(gè)問題的具體原因就是改為多入口之后，在HtmlWebpackPlugin中會對每一個(gè)入口文件都執(zhí)行一遍emit中所有代碼邏輯，正是這個(gè)原因影響了速度。

在看一些參考資料之后，我發(fā)現(xiàn)已經(jīng)有現(xiàn)有的造輪子可以使用了，就是 [html-webpack-plugin-for-multihtml] (https://github.com/daifee/html-webpack-plugin-for-multihtml)

該插件通過在webpack done鉤子函數(shù)中設(shè)置相關(guān)變量，來保證原h(huán)tml-webpack-plugin插件中emit僅觸發(fā)一次全部流程。來達(dá)到提速的效果。升級以后，修改文案，HMR的速度從原來的秒級改為毫秒級。

可以看出 asset optimization已經(jīng)優(yōu)化到毫秒級。

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論