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
})],
}
};
}