# 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:
```js
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:

```js
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:
```js
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](https://webpack.js.org/configuration/configuration-types/#exporting-multiple-configurations)
* [test repository](https://github.com/how-to-js/webpack-array-vs-object)
* [my video course about webpack](https://bit.ly/WebpackCourse)

# 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.