webpack chunk相關分享

還在爲學不會webpack而發愁麼,還在由於概念過多而煩惱嘛 歡迎你們來看本次分享javascript

分享內容簡介:
  1. 什麼是webpack(webpack簡介、webpack工做流程)
  2. 什麼是chunk(chunk相關概念、splitChunks插件的使用)
  3. webpack 打包優化方案(經常使用優化插件&打包優化方案)
  4. 相關內容擴展(webpack v3 v4區別、hash、scripts配置、path相關概念等)

什麼是webpack?

img1

前端頁面效果愈來愈酷炫、功能愈來愈複雜 而前端工程師們爲了更方便的開發提升開發效率進行了一系列de探索 模塊化思想的提出啊 將複雜的程序分割成更小的文件css

這些年優秀的框架層出不窮react vue angular es6這種在javascript基礎上拓展的新的語法規範 less sass css處理器等等等html

全部的事物都是具備雙面性的 有利有弊 大大提升開發效率 的同時 又爲後期維護形成了困擾 由於利用這些工具的文件每每不能直接被瀏覽器識別 須要手動處理 很影響開發進度 而在這一個環境背景下 webpack產生……前端

咱們來看一下官方介紹圖vue

img2

webpack能夠看作是模塊打包機,而它主要作的事情呢就是解析你的代碼結構 同時找到javascript模塊以及其餘的一些瀏覽器不能直接識別的拓展語言(scss、es6等) 將其轉換並打包爲合適的格式供瀏覽器使用java

webpack具體爲咱們作了哪些事情呢 彆着急往下看~node

img3

能夠大體分爲如下四類:react

  1. 公共代碼抽離沒有用到的代碼不進行打包 減小總體代碼量
  2. babel-loader、sass-loader等來處理瀏覽器不能直接識別的語言 提升開發效率
  3. webpack-server 開發模式優化開發流程 減小工做量
  4. 文件的混淆壓縮 減小頁面渲染時間提升系統安全性

使用先後有什麼具體的變化麼 咱們下面詳細的舉一些例子場景來看webpack

img4

使用前 使用後
代碼過於冗餘 維護難度大 以入口文件爲基點建立關係圖 忽略無用代碼
相同文件屢次請求 資源浪費嚴重 頁面加載速度慢 用戶體驗差 抽離公共chunk 避免重複引用
開發更改文件 瀏覽器卻優先讀取緩存致使沒法生效 經過hash命名 避免瀏覽器緩存影響
代碼註釋刪除繁瑣系統安全性沒有保障 插件清除註釋 加密 壓縮 混淆一步到位
開發模式下須要修改後須要頻繁回到瀏覽器刷新查看效果 開發效率低下 HMR 熱更新動態更新視圖 避免繁瑣操做
開發技術工具繁多 對開發人員技術要求高 豐富的插件、loader自動編譯 下降開發難度

聽到這裏 是否是以爲webpack很神奇 而webpack之因此有這些優勢其實全是源於其設計理念 咱們看一下它的工做流程就會大概明白了他的實現原理了git

img5

webpack 從入口文件開始遞歸的創建一個依賴關係圖,涉及到的全部文件內容都將被webpack封裝爲獨立的模塊函數,按照咱們設置的配置文件 進行模塊函數的封裝打包成一個個chunk,最終經過script標籤引入的形式注入到相應的模板視圖文件中也就是咱們常見的html文件 經過依賴第一步生成的 manifest 文件 管理文件的加載運行

咱們可控可配置的通常是第二三步驟 咱們詳細的看一下

img6

看完上面的 webpack 打包流程的介紹,是否是對webpack打包過程有了一些理解呢 而咱們本次分享的重點,則是學習對chunk有必定的理解和一些自定義化的構建配置

什麼是chunk?

Chunk 能夠簡單理解爲模塊函數的集合也就是「代碼塊」,經過使用webpack打包處理能夠將代碼中的多個入口文件、公共引用文件、異步加載文件等抽離成單獨的個體、也就是咱們打包後產生的一個個文件,咱們能夠利用chunk來提升 打包效率節省加載時間 更合理的利用瀏覽器的緩存等…

本次分享代碼使用 webpack v4版本

經過四個demo來模擬打包處理的四種狀況

文件引用關係圖:

img7

提示:爲了方便你們理解,代碼使用的是最基本的代碼結構 你們能夠經過demo瞭解一下 webpack打包經常使用插件 clean-webpack-plugin、html-webpack-plugin、webpack-merge、node環境全局變量process.env使用等

咱們會發現webpack v4版本默認已經將咱們的代碼進行必定程度的拆分打包 具體的打包規則以下:

  1. 重複引用的chunk和包含來自node_modules文件夾下的模塊
  2. 在壓縮前不小於30kb
  3. 按需加載併發請求量不大於5
  4. 初始化加載併發請求量不大於3

而這也就涉及到webpack v3 v4版本最大的變化 就是splitChunksPlugin替換commonChunksPlugin

module.exports = { //...
   optimization: {
     splitChunks: { 
        chunks: ‘async’ ,                          //能夠選擇對哪些chunk進行優化(all|async|initial) 
        minSize: 30000, // 要生成的chunk的最小大小(b) 
        minChunks: 1,   //分割前必須共享模塊的最小引用次數 
        maxAsyncRequests: 5,    //按需加載 最大並行請求量 
        maxInitialRequests: 3,  //初始化頁面 最大並行請求量 
        automaticNameDelimiter: ‘~’,            //chunk通常名稱格式爲(例如vendors~main.js)該項指分隔符 
        name: true,                                 //chunk的名稱 (true時將自動生成名稱) 若是名稱和入口點名稱不相符則刪除入口點 
        cacheGroups: {  //緩存組能夠繼承和覆蓋splitChunks.*所有屬性 
        vendors: {
            test: /[\\/]node_modules[\\/]/, //test屬性只有在cache group中操做 正則匹配chunk放到該緩存組中 
            priority: -10       //priority屬性只有在cache group中操做 優先級(默認組優先級爲負) }, 
            default: {
                minChunks: 2,
                priority: -20, 
                reuseExistingChunk: true,          //reuseExistingChunk屬性只有在cache group操做 是否可使用已存在的chunk 若是知足條件的chunk已存在就不會再建立新的chunk 
               filename: '[name].bundle.js'     //打包生成文件名稱
            }
        }
     } 
   }
};

複製代碼

測試上面的配置可使用代碼案例哦~ 這裏

這裏你們可能和我同樣對默認規則的三、4條理解不是很清楚 上面所說的按需並行請求量和初始化併發請求量對應的分別是 maxAsyncRequest 和 maxInitialREquests這兩個屬性 而這兩個屬性實際上是爲了解決打包過於細化 請求量過多的問題 咱們若是使用cacheGroups 進行劃分有可能會出現不少chunk 而這種狀況不是咱們所指望的 若是最終chunk數量超過了咱們設置的最大值 webpack則會按照必定規則將chunk合併至最大值 若是還不是很清楚的話 就邊看頁面scripts請求數量 邊調最大值看看就懂了 = =

webpack打包優化方案

  1. 減小打包時間(抽離公共庫文件) : DllPlugin&DllReferencePlugin 案例
  2. 可視化工具:webpack-bundle-analyzer 案例
  3. webpack插件耗時查看工具:speed-measure-webpack-plugin 案例
  4. 嘗試使用 DllPlugin&DllReferencePlugin 後你會發現沒法動態添加vendor.dll.js文件 並且沒法添加hash值 這裏推薦 html-webpack-include-assets-plugin 案例

相關知識拓展

webpack v3 v4區別有哪些呢?

v4 mode關鍵字有development、production兩個選項 默認爲production 同時如同上面提到的新增了默認打包規則 development 模式下,默認開啓了NamedChunksPlugin 和NamedModulesPlugin方便調試,提供了更完整的錯誤信息,更快的從新編譯的速度。

production 模式下,因爲提供了splitChunks和minimize,因此基本零配置,代碼就會自動分割、壓縮、優化,同時 webpack 也會自動幫你 Scope hoisting 和 Tree-shaking。

Scope Hoisting 的實現原理其實很簡單:分析出模塊之間的依賴關係,儘量的把打散的模塊合併到一個函數中去,但前提是不能形成代碼冗餘。

Tree-shaking的本質是消除無用的js代碼。無用代碼消除在普遍存在於傳統的編程語言編譯器中,編譯器能夠判斷出某些代碼根本不影響輸出,而後消除這些代碼

更多的v3 v4區別能夠看這裏: 手摸手,帶你用合理的姿式使用webpack4

相關連接

(๑•̀ㅂ•́)و✧詳細內容可查閱ppt demo & pptwebpack chunk分享視頻 by糖·少 提取碼:4gvj

Thanks !

原文連接: tech.meicai.cn/detail/98, 也可微信搜索小程序「美菜產品技術團隊」,乾貨滿滿且每週更新,想學習技術的你不要錯過哦。

相關文章
相關標籤/搜索