Webpack has the feature of accepting an array of configuration objects instead of one object. Unfortunately, it comes with a performance penalty - in this article, I'll look at how serious the slow-down can get.
Code
I'll have 10 files in the benchmark, src/a.js
, src/b.js
, etc. Each of the failed contains:
import $ from "jquery";
$(".a").html("a");
Where:
- the letter makes sure there is no weird optimization used thanks to all files having the same content
-
jquery
makes the build size non-trivial
Simple configuration
There are 2 configuration approaches to be compared.
Object configuration
Here there is 1 object, which defines multiple entry points:
module.exports = {
entry: {
a: "./src/a",
b: "./src/b",
...
},
};
The time
output for the build is:
real 0m9,507s
user 0m29,622s
sys 0m0,438s
It tasks about 9.5s to run the build.
Array
In an array configuration, we have multiple configuration objects returned together. It allows for greater flexibility:
module.exports = [
{
entry: {
a: "./src/a",
},
},
{
entry: {
b: "./src/b",
},
},
...
];
The time
output:
real 0m14,622s
user 0m48,990s
sys 0m0,877s
It took 14.5s to build the same files, about 50% longer.
Build with splitting
The difference becomes even starker when we introduce splitting. Splitting allows webpack to optimize & build only once parts that are used in many places. This optimization is done in the context of each configuration object - so if we use a configuration array, we won't see improvements.
Object
b/webpack.object.js
:
i: "./src/i",
j: "./src/j",
},
+ optimization: {
+ splitChunks: {
+ // include all types of chunks
+ chunks: "all",
+ },
+ },
};
Build times
:
real 0m3,074s
user 0m5,724s
sys 0m0,161s
About 3s build time.
Array
If we had more complex cases for each entry point, we could see some speed improvements, but there is no chance for this simplified example.
webpack.array.js
@@ -3,50 +3,110 @@ module.exports = [
entry: {
a: "./src/a",
},
+ optimization: {
+ splitChunks: {
+ // include all types of chunks
+ chunks: "all",
+ },
+ },
},
{
entry: {
b: "./src/b",
},
+ optimization: {
+ splitChunks: {
+ // include all types of chunks
+ chunks: "all",
+ },
+ },
},
...
time
output:
real 0m14,904s
user 0m48,754s
sys 0m1,154s
The build took almost 15s, five times slower than with the object configuration.
Links
Summary
In this article, we have seen a build time benchmark for 2 formats of webpack configuration. One can understand the array configuration as a shortcut to run multiple, unrelated builds - there will not be many optimizations done by wepback.
Top comments (2)
Nice research :)
Never used array config, but results are surprising, to say the least.
I did, and it wasn't fun:) It was very slow, so we had some package to parallelize webpack run. At that point I couldn't build on my local machine because it was freezing my computer. All the issue were gone after migrating back to object.