What is the performance impact of using array configuration in webpack

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

• documentation
• test repository
• video course about webpack

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.

Comments

[Paweł Kowalski]

Nice research :)

Never used array config, but results are surprising, to say the least.

[Marcin Wosinek]

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.