起因

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

基本會(huì)卡在

94% assets optimization95% emitting

這個(gè)步驟很久

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

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

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

那么問(wèn)題來(lái)了，怎么優(yōu)化這里？

優(yōu)化思路-1

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

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

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

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

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

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

優(yōu)化思路-2

其實(shí)這個(gè)問(wèn)題的具體原因就是改為多入口之后，在HtmlWebpackPlugin中會(huì)對(duì)每一個(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)

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

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

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

最新評(píng)論