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.

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.

What is the performance impact of using array configuration in webpack

Comments

webpack optimization

What is the performance impact of chunk splitting in webpack

More from this blog

Changes in programming made possible with AI

Advantages of unit testing—with examples in Jasmine

Pure functions and basic tests in Jasmine

How to prepare for a job interview

How to build a demo project

Code

Simple configuration

Object configuration

Array

Build with splitting

Object

Array

Links

Summary

Command Palette

Comments

webpack optimization

What is the performance impact of chunk splitting in webpack

More from this blog

Code

Simple configuration

Object configuration

Array

Build with splitting

Object

Array

Links

Summary