Optimize Build Speed in webpack 4

by user

Auto Draft

Recently I did research on how to optimize build time with webpack 4. This article shows the results of what I have verified.

Table of Contents

  • Speed ​​verification by different versions of Node
  • Speed ​​verification with multi-core
  • Speed ​​verification with cache applied

First of all, make sure your webpack and Node versions are up to date. The following is my environment:

Module Version
Webpack Version 4.40.2
Node Version v12

Speed ​​Verification by Different Versions of Node

Node.js is more and more optimized every time the version has updated. The latest version is 12.11.1, and the LTS is 10.16.3. I measured the build time by each Node version.

Result

Node Version Build Time
v6 5826ms
v7 5789ms
v8 3491ms
v9 3662ms
v10 3301ms
v11 3361ms
v12 3290ms

Conclusion

Although there is a version with a degradation between v8 and v9, as the version goes up, the build time has been reduced. Surprisingly, the file size after compilation among the versions did not change. All of the file size were the same. Only the build times were different, respectively.


Speed ​​Verification With Multi-Core

The file compression plug-in uglyfy-webpack-plugin on the official webpack page supports building with multiple CPU cores. This plug-in is supposed to be included in webpack by default in v1.0.0, but now it needs to be manually installed via npm.

npm install --save-dev uglifyjs-webpack-plugin

The plug-in reference has the following annotation:

Parallelization can speedup your build significantly and is therefore highly recommended.

It is highly recommended to increase the build speed. In order to apply multi-core on building process, it is required to enable the parallel property or specify the number of cores. The code is as follows.

optimization: {
  // NOTE: Use multi-process parallel running to improve the build speed.
  //       If you have enough CPU core more than 2, you can set as such `parallel: 4`,
  //       then would get the build speed faster.
  minimizer: [
    new UglifyJsPlugin({
      parallel: true, // ex) core number 4 
    })
  ],
} 

Result

CPU Core Number Build Time
Single-Core 66395ms
Dual-Core 54614ms
Quad-Core 51362ms
* NOT accurate because the verification terminal does not support it.

Conclusion

In terms of getting a faster build speed, it is effective to set parallel properties for multi-core processes. Especially, when building large projects, this function is super helpful.

Although my laptop doesn’t equip a quad core, I tried to set the number of cores to four and measured. As a result, it seems to be slightly faster than the dual core, but since my laptop doesn’t support quad core, it must have been measuring with dual core. The difference in build time between the dual core and quad core is probably the range of tolerance.

Indeed, on the webpack side, the setting of the number of cores is used in the following code, and it seems that the number of cores to be used is determined by looking at the number of cores of the OS.

os.cpus().length — 1

Speed ​​Verification With Cache Applied

The UglifyJsPlugin has a cache property setting (default: false). If enabled, a cache will be created into node_modules/.cache/uglifyjs-webpack-plugin, which will be referenced from the next time forward.

new UglifyJsPlugin({
  cache: true
})

Result

Before Cache 66395ms
After Cache Applied 15884ms

After applying the cache, the build time was dramatically reduced. Furthermore, I tried to measure the build time corresponding to the multi-core.

 new UglifyJsPlugin({
    parallel: true,
    cache: true
  })
  ```

|||
|:--|:--|
|Cache + Multi Core|12947ms|

#### Conclusion
Since it is necessary to accumulate in the cache, the first build time had no changes. But once the cache was created after the first build had finished, the build time after the second time was dramatically reduced.
Be careful of modification. If the file is modified again after creating a cache, it will be the normal build time. Nevertheless, it seems effective because the build speed still gets faster by the unchanged files.

---

## Overall
It turns out the build time is faster due to the difference in the version of Node. Especially since Node at version 8 has been improved considerably, just upgrading the Node version is effective.

In addition, when setting the cache property to enabled, the build time is reduced by files that have not changed since the second time. Therefore, if there are multiple projects to build and some of the files in the projects do not have to change, there will be a reduction in the overall build time.

In such a case, it may be better to escape the target files, however. Well, if cache property is applied and there is allowance to use the multi-core, the build time will be further shortened.

Here is my final `webpack.config.js` example.

```js
const UglifyJsPlugin = require("uglifyjs-webpack-plugin");

module.exports =  {
    mode: 'production',
    entry: {
      pageOne: './src/pageOne/index.js',
      pageTwo: './src/pageTwo/index.js',
      pageThree: './src/pageThree/index.js'
    },
    output: {
      filename: '[name].js',
      path: __dirname + '/dist'
    },
    module: {
      rules: [{ 
          test: /\.js$/,
          exclude: /node_modules/,
          use: {
              loader: 'babel-loader',
              options: {
                presets: ['@babel/preset-env']
              }
            }
      }]
    },
    optimization: {
      // NOTE: Use multi-process parallel running to improve the build speed
      minimizer: [new UglifyJsPlugin({
        parallel: true,
        cache: true
      })],
    }
  };
}

You may also like

Leave a Comment

* By using this form you agree with the storage and handling of your data by this website.

Close Bitnami banner
Bitnami