怎樣對Webpack構建速度進行優化

怎樣對Webpack構建速度進行優化，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

如何輸出Webpack構建分析

•  輸出Webpack構建信息的.json文件：webpack --profile --json > starts.json 

1.  --profile:記錄構建中的耗時信息

2.  --json:以json格式輸出構建結果，只輸出一個json文件（包含所有的構建信息）

•  web可視化查看構建分析：得到了webpack構建信息文件starts.json，如何進行很好的可視化查看？

        1. 方案一：通過可視化分析工具Webpack Analyse，是個在線Web應用，上傳starts.json文件就可以；

        2. 方案二：安裝webpack-bundle-analyzer工具npm i -g webpack-bundle-analyzer,生成starts.json后直接在其文件夾目錄執行webpack-bundle-analyzer后，瀏覽器會打開對應網頁并展示構建分析文檔地址webpack-bundle-analyzer

        3. webpack-dashboard是一款統計和優化webpack日志的工具，可以以表格形勢展示日志信息。其中包括構建過程和狀態、日志以及涉及的模塊列表

        4. jarvis是一款基于webapck-dashboard的webpack性能分析插件，性能分析的結果在瀏覽器顯示，比webpack-bundler-anazlyer更美觀清晰GitHub文檔地址

•   npm i -D webpack-jarvis

•   webpack.config.js配置：   

const Jarvis = require("webpack-jarvis");     plugins: [       new Jarvis({         watchOnly: false,         port: 3001 // optional: set a port       })     ];

•   port:監聽的端口，默認1337，監聽面板將監聽這個端口，通常像http://localhost:port/

•   host:域名，默認localhost,不限制域名。

•   watchOnly:僅僅監聽編譯階段。默認為true,如果高為false，jarvis不僅僅運行在編譯階段，在編譯完成后還保持運行狀態。

•   界面：看到構建時間為：Time: 11593ms(作為優化時間對比)

webpack配置優化

•  webpack在啟動時會從配置的Entry出發，解析出文件中的導入語句，再遞歸解析。

•  對于導入語句Webpack會做出以下操作：

        1. 根據導入語句尋找對應的要導入的文件；

        2. 在根據要導入的文件后綴，使用配置中的Loader去處理文件（如使用ES6需要使用babel-loader處理）

•  針對這兩點可以優化查找途徑

1. 優化Loader配置

•   Loader處理文件的轉換操作是很耗時的，所以需要讓盡可能少的文件被Loader處理  

1. {    

2.      test: /\.js$/,    

3.      use: [    

4.          'babel-loader?cacheDirectory',//開啟轉換結果緩存    

5.      ],    

6.      include: path.resolve(__dirname, 'src'),//只對src目錄中文件采用babel-loader    

7.      exclude: path.resolve(__dirname,' ./node_modules'),//排除node_modules目錄下的文件    

8.  },  

2. 優化resolve.modules配置

•   resolve.modules用于配置webpack去哪些目錄下尋找第三方模塊，默認是['node_modules']，但是，它會先去當前目錄的./node_modules查找，沒有的話再去../node_modules最后到根目錄；

•   所以當安裝的第三方模塊都放在項目根目錄時，就沒有必要安默認的一層一層的查找，直接指明存放的絕對位置   

resolve: {              modules: [path.resolve(__dirname, 'node_modules')],          }

3. 優化resolve.extensions配置

•   在導入沒帶文件后綴的路徑時，webpack會自動帶上后綴去嘗試詢問文件是否存在，而resolve.extensions用于配置嘗試后綴列表；默認為extensions:['js','json'];

•   及當遇到require('./data')時webpack會先嘗試尋找data.js，沒有再去找data.json；如果列表越長，或者正確的后綴越往后，嘗試的次數就會越多

•   所以在配置時為提升構建優化需遵守：

          1. 頻率出現高的文件后綴優先放在前面；

          2. 列表盡可能的小；

          3. 書寫導入語句時，盡量寫上后綴名

•   因為項目中用的jsx較多，所以配置extensions: [".jsx",".js"],

•  基本配置后查看構建速度：Time: 10654ms;配置前為Time: 11593ms 

使用DllPlugin優化

•  在使用webpack進行打包時候，對于依賴的第三方庫，如react，react-dom等這些不會修改的依賴，可以讓它和業務代碼分開打包；

•  只要不升級依賴庫版本，之后webpack就只需要打包項目業務代碼，遇到需要導入的模塊在某個動態鏈接庫中時，就直接去其中獲取；而不用再去編譯第三方庫，這樣第三方庫就只需要打包一次。

•  接入需要完成的事：

        1. 將依賴的第三方模塊抽離，打包到一個個單獨的動態鏈接庫中

        2. 當需要導入的模塊存在動態鏈接庫中時，讓其直接從鏈接庫中獲取

        3. 項目依賴的所有動態鏈接庫都需要被加載

•  接入工具(webpack已內置)

        1. DllPlugin插件：用于打包出一個個單獨的動態鏈接庫文件；

        2. DllReferencePlugin:用于在主要的配置文件中引入DllPlugin插件打包好的動態鏈接庫文件

•  配置webpack_dll.config.js構建動態鏈接庫 

const path = require('path');  const DllPlugin = require('webpack/lib/DllPlugin');  module.exports = {      mode: 'production',      entry: {          // 將React相關模塊放入一個動態鏈接庫          react: ['react','react-dom','react-router-dom','react-loadable'],          librarys: ['wangeditor'],          utils: ['axios','js-cookie']      },      output: {          filename: '[name]-dll.js',          path: path.resolve(__dirname, 'dll'),          // 存放動態鏈接庫的全局變量名，加上_dll_防止全局變量沖突          library: '_dll_[name]'      },      // 動態鏈接庫的全局變量名稱，需要可output.library中保持一致，也是輸出的manifest.json文件中name的字段值      // 如react.manifest.json字段中存在"name":"_dll_react"      plugins: [          new DllPlugin({              name: '_dll_[name]',              path: path.join(__dirname, 'dll', '[name].manifest.json')          })      ]  }

•  webpack.pro.config.js中使用 

const DllReferencePlugin = require('webpack/lib/DllReferencePlugin');  ...  plugins: [      // 告訴webpack使用了哪些動態鏈接庫          new DllReferencePlugin({              manifest: require('./dll/react.manifest.json')          }),          new DllReferencePlugin({              manifest: require('./dll/librarys.manifest.json')          }),          new DllReferencePlugin({              manifest: require('./dll/utils.manifest.json')          }),  ]

•  注意：在webpack_dll.config.js文件中，DllPlugin中的name參數必須和output.library中的一致；因為DllPlugin的name參數影響輸出的manifest.json的name；而webpack.pro.config.js中的DllReferencePlugin會讀取manifest.json的name，將值作為從全局變量中獲取動態鏈接庫內容時的全局變量名

•  執行構建

        1. webpack --progress --colors --config ./webpack.dll.config.js

        2. webpack --progress --colors --config ./webpack.prod.js

•  html中引入dll.js文件

•  構建時間對比：["11593ms","10654ms","8334ms"]

HappyPack并行構建優化

•  核心原理：將webpack中最耗時的loader文件轉換操作任務，分解到多個進程中并行處理，從而減少構建時間。

•  HappyPack

•  接入HappyPack

        1. 安裝：npm i -D happypack

        2. 重新配置rules部分,將loader交給happypack來分配：

const HappyPack = require('happypack');  const happyThreadPool = HappyPack.ThreadPool({size: 5}); //構建共享進程池，包含5個進程  ...  plugins: [      // happypack并行處理      new HappyPack({          // 用ID來代表當前HappyPack是用來處理一類特定文件的，與rules中的use對應          id: 'babel',          loaders: ['babel-loader?cacheDirectory'],//默認設置loader處理          threadPool: happyThreadPool,//使用共享池處理      }),      new HappyPack({          // 用唯一ID來代表當前HappyPack是用來處理一類特定文件的，與rules中的use對應          id: 'css',          loaders: [              'css-loader',              'postcss-loader',              'sass-loader'],              threadPool: happyThreadPool      })  ],  module: {      rules: [      {          test: /\.(js|jsx)$/,          use: ['happypack/loader?id=babel'],          exclude: path.resolve(__dirname,' ./node_modules'),      },      {          test: /\.(scss|css)$/,          //使用的mini-css-extract-plugin提取css此處，如果放在上面會出錯          use: [MiniCssExtractPlugin.loader,'happypack/loader?id=css'],          include:[              path.resolve(__dirname,'src'),              path.join(__dirname, './node_modules/antd')          ]      },  }

•  參數：

        1. threads：代表開啟幾個子進程去處理這一類文件，默認是3個；

        2. verbose:是否運行HappyPack輸出日志，默認true；

        3. threadPool：代表共享進程池，即多個HappyPack示例使用一個共享進程池中的子進程去處理任務，以防資源占有過多

代碼壓縮用ParallelUglifyPlugin代替自帶的 UglifyJsPlugin插件

•  自帶的JS壓縮插件是單線程執行的，而webpack-parallel-uglify-plugin可以并行的執行

•  配置參數：

        1. uglifyJS: {}：用于壓縮 ES5 代碼時的配置，Object 類型

        2. test: /.js$/g:使用正則去匹配哪些文件需要被 ParallelUglifyPlugin 壓縮，默認是 /.js$/

        3. include: []:使用正則去包含被壓縮的文件，默認為 [].

        4. exclude: []: 使用正則去包含不被壓縮的文件，默認為 []

        5. cacheDir: ''：緩存壓縮后的結果，下次遇到一樣的輸入時直接從緩存中獲取壓縮后的結果并返回，默認不會緩存，開啟緩存設置一個目錄路徑

        6. workerCount: ''：開啟幾個子進程去并發的執行壓縮。默認是當前運行電腦的 CPU 核數減去1

        7. sourceMap: false：是否為壓縮后的代碼生成對應的Source Map, 默認不生成

...  minimizer: [      // webpack:production模式默認有配有js壓縮，但是如果這里設置了css壓縮，js壓縮也要重新設置,因為使用minimizer會自動取消webpack的默認配置      new optimizeCssPlugin({          assetNameRegExp: /\.css$/g,          cssProcessor: require('cssnano'),          cssProcessorOptions: { discardComments: { removeAll: true } },          canPrint: true      }),      new ParallelUglifyPlugin({          cacheDir: '.cache/',          uglifyJS:{              output: {             // 是否輸出可讀性較強的代碼，即會保留空格和制表符，默認為輸出，為了達到更好的壓縮效果，可以設置為false                  beautify: false,          //是否保留代碼中的注釋，默認為保留，為了達到更好的壓縮效果，可以設置為false                  comments: false              },              compress: {              //是否在UglifyJS刪除沒有用到的代碼時輸出警告信息，默認為輸出                  warnings: false,              //是否刪除代碼中所有的console語句，默認為不刪除，開啟后，會刪除所有的console語句                  drop_console: true,              //是否內嵌雖然已經定義了，但是只用到一次的變量，比如將 var x = 1; y = x, 轉換成 y = 1, 默認為否                  collapse_vars: true,              }          }  }),  ]

•  構建結果對比：["11593ms","10654ms","8334ms","7734ms"]

•  整體構建速度從12000ms降到現在的8000ms

“積跬步、行千里”—— 持續更新中~，喜歡的話留下個贊和關注哦！

•  往期經典好文：

•   你不知道的CORS跨域資源共享

•   Koa日志中間件封裝開發（log4js）

•   團隊合作必備的Git操作

•   使用pm2部署node生產環境

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。