前言
開發多頁應用的時候，如果不對webpack打包進行優化，當某個模塊被多個入口模塊引用時，它就會被打包多次（在最終打包出來的某幾個文件里，它們都會有一份相同的代碼）。當項目業務越來越複雜，打包出來的代碼會非常冗餘，文件體積會非常龐大。大體積文件會增加編譯時間，影響開發效率；如果直接上線，還會拉長請求和加載時長，影響網站體驗。作為一個追求極致體驗的攻城獅，是不能忍的。所以在多頁應用中優化打包尤為必要。那麼如何優化webpack打包呢？
一、概念
在一切開始前，有必要先理清一下這三個概念：
二、問題分析
首先，簡單分析下，我們剛才提到的打包問題：
弄明白了問題的原因，那麼大致的解決思路也就出來了：
optimization.splitChunks
webpack提供了一個非常好的內置插件幫我們實現這一需求：CommonsChunkPlugin。不過在webpack4中CommonsChunkPlugin被刪除，取而代之的是optimization.splitChunks,所幸的是optimization.splitChunks更強大！
三、實現
通過一個多頁應用的小demo，我們一步一步來實現上述思路的配置。
demo目錄結構：
代碼邏輯很簡單，index模塊中引用了a和b2個模塊，a模塊中引用了c模塊和jquery庫，b模塊中也引用了c模塊和jquery庫，c是一個獨立的模塊沒有其他依賴。
index.js代碼如下：
a.js代碼如下：
b.js代碼如下：
c.js代碼如下：
- 基本配置
- webpack先不做優化，只做基本配置，看看效果。項目配置了2個入口，搭配html-webpack-plugin實現多頁打包：
- 在開發模式下運行webpack：
- 可以看到，打包出兩個html和兩個體積很大的（300多K）的文件a.js,index.js。
- 進入dist目錄檢查js文件：
- 看，同樣的代碼c和jquery被打包了2遍。
- 初步添加splitChunks優化配置
- 首先解決相同代碼打包2次的問題，我們需要讓webpack把c和jquery提取出來打包為公共模塊。
- 在webpack配置文件添加splitChunks：
- -cacheGroups
- -name
- -chunks
- 再次打包：
- 可以看到a.js,index.js從300多K減少到6點幾K。同時增加了一個common.js文件，並且兩個打包入口都自動添加了common.js這個公共模塊：
- 進入dist目錄，依次查看這3個js文件：
- 發現，提是提取了，但是似乎跟我們預料的不太一樣，所有的模塊都跑到common.js里去了。
- 這是因為我們沒有告訴webpack（splitChunks）什麼樣的代碼為公共代碼，splitChunks默認任何模塊都會被提取。
- -minChunks
- splitChunks是自帶默認配置的，而緩存組默認會繼承這些配置，其中有個minChunks屬性：
- 我們上面沒有配置minChunks，只配置了name和chunk兩個屬性，所以minChunks的默認值1生效。也難怪所有的模塊都被抽離到common.js中了。
- 優化一下，在緩存組裡配置minChunks覆蓋默認值：
- 然後運行webpack
- 可以看到有2個文件的大小發生了變化：common.js由314K減小到311K，index.js由6.22K增大到7.56K。
- 進入dist目錄查看：
- a.js里依然不包含任何模塊的代碼（正常，因為a作為模塊被index引入了一次，又作為入口被webpack引入了一次，所以a是有2次引用的）。
- 配置多個拆分規則
- 3.1實現代碼分離，拆分第三方庫
- 接下來，我希望公共模塊common.js中，業務代碼和第三方模塊jquery能夠剝離開來。
- 我們需要再添加一個拆分規則。
- 我給cacheGroups添加了一個vendors屬性（屬性名可以自己取，只要不跟緩存組下其他定義過的屬性同名就行，否則後面的拆分規則會把前面的配置覆蓋掉）。
- -minSize
- minSize設置的是生成文件的最小大小，單位是位元組。如果一個模塊符合之前所說的拆分規則，但是如果提取出來最後生成文件大小比minSize要小，那它仍然不會被提取出來。這個屬性可以在每個緩存組屬性中設置，也可以在splitChunks屬性中設置，這樣在每個緩存組都會繼承這個配置。這裡由於我的demo中文件非常小，為了演示效果，我把minSize設置為30位元組，好讓公共模塊可以被提取出來，正常項目中不用設這麼小。
- -priority
- priority屬性的值為數字，可以為負數。作用是當緩存組中設置有多個拆分規則，而某個模塊同時符合好幾個規則的時候，則需要通過優先級屬性priority來決定使用哪個拆分規則。優先級高者執行。我這裡給業務代碼組設置的優先級為-20，給第三方庫組設置的優先級為-10，這樣當一個第三方庫被引用超過2次的時候，就不會打包到業務模塊里了。
- -test
- test屬性用於進一步控制緩存組選擇的模塊，與chunks屬性的作用有一點像，但是維度不一樣。test的值可以是一個正則表達式，也可以是一個函數。它可以匹配模塊的絕對資源路徑或chunk名稱，匹配chunk名稱時，將選擇chunk中的所有模塊。我這裡用了一個正則/[\\\\/]node_modules[\\\\/]/來匹配第三方模塊的絕對路徑，因為通過npm或者yarn安裝的模塊，都會存放在node_modules目錄下。
- 運行一下webpack：
- 可以看到新產生了一個叫vendor.js的文件（name屬性的值），同時common.js文件體積由原來的311k減少到了861bytes！
- 進入dist目錄，檢查js文件：
- 現在，我們在上一步的基礎上，成功從common.js里把第三方庫jquery抽離出來放到了vendor.js里。
- 3.2拆分指定文件
- 如果我們還想把項目中的某一些文件單獨拎出來打包（比如工程本地開發的組件庫），可以繼續添加拆分規則。比如我的src下有個locallib.js文件要單獨打包，假設a.js中引入了它。
- 可以這麼配置：
- 我在緩存組下又新增了一個拆分規則，通過test正則指定我就要單獨打包src/locallib.js文件，並且把優先級設置為-9，這樣當它被多次引用時，不會進入其他拆分規則組，因為另外兩個規則的優先級都比它要低。
- 運行webpack打包後：
- 可以看到新產生了一個locallib.js文件。進入dist目錄查看：
- 現在我們又在上一步的基礎上獨立打包了一個指定的模塊locallib.js。
- 至此，我們就成功實現了抽離公共模塊、業務代碼和第三方代碼剝離、獨立打包指定模塊。
- 對比一下，優化前，打包出來js一共有633KB：
- 優化後，打包出來js一共不到330KB：
- 優化打包後的文件分類清晰，體積比優化前縮小了幾乎50%，有點小完美是不是！擊掌！這還只是我舉的一個簡單例子，在實際多頁應用中，優化力度說不定還不止這麼多。
- 小結
- webpack很強大，以上只是冰山一角，但是只要掌握了上述optimization.splitChunks的核心配置，我們就可以幾乎隨心所欲地按照自己的想法來拆分優化代碼控制打包文件了，是不是很酷？玩轉代碼拆分，你也可以！
- 歡迎交流～
- 本文的完整webpack配置和demo源碼可以在這裡獲取：https://github.com/yc111/webpack-optimize-demo
- 總結
- 以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對小編的支持。