很多人都說webpack複雜，難以理解，很大一部分原因是webpack是基於配置的，可配置項很多，並且每個參數傳入的形式多種多樣（可以是字符串、數組、對象、函數。。。），文檔介紹也比較模糊，這麼多的配置項各種排列組合，想想都複雜。而gulp基於流的方式來處理文件，無論從理解上，還是功能上都很容易上手。
上面簡單對比了webpack與gulp配置的區別，當然這樣比較是有問題的，gulp並不能進行模塊化的處理。這裡主要是想告訴大家使用gulp的時候，我們能明確的知道js文件是先進行babel轉譯，然後進行壓縮混淆，最後輸出文件。而webpack對我們來說完全是個黑盒，完全不知道plugins的執行順序。正是因為這些原因，我們常常在使用webpack時有一些不安，不知道這個配置到底有沒有生效，我要按某種方式打包到底該如何配置？
零配置就意味著webpack4具有默認配置，webpack運行時，會根據mode的值採取不同的默認配置。如果你沒有給webpack傳入mode，會拋出錯誤，並提示我們如果要使用webpack就需要設置一個mode。
如果想查看更多webpack4相關的默認配置，到這裡來。可以看到webpack4把很多插件相關的配置都遷移到了optimization中，但是我們看看官方文檔對optimization的介紹簡直寥寥無幾，而在默認配置的代碼中，webpack對optimization的配置有十幾項，反正我是怕了。
這裡改動比較小，只要替換下插件，然後改動下css相關的loader就行了：
使windows的時候，我們經常會看到一些.dll文件，dll文件被稱為動態鏈接庫，裡面包含了程序運行時的一些動態函數庫，多個程序可以共用一個dll文件，可以減少程序運行時的物理內存。
前面的優化都是優化打包速度，或者減少重複模塊的。這裡有一種優化方式，能夠減少代碼量，並且減少客戶端的運行時間。
這裡簡單羅列了一些webpack的優化策略，但是有些優化策略還是還是要酌情考慮。比如多進程跑loader，如果你項目比較小，開了之後可能變慢了，因為本來打包時間就比較短，用來fork子進程的時間，說不定都已經跑完了。記住過早的優化就是萬惡之源。
學會這個，就擁有刷屏10億用戶的入場券！