DEV Community

Marcin Wosinek
Marcin Wosinek

Posted on • Updated on • Originally published at how-to.dev

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");
Enter fullscreen mode Exit fullscreen mode

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",
    ...
  },
};
Enter fullscreen mode Exit fullscreen mode

The time output for the build is:

real    0m9,507s
user    0m29,622s
sys     0m0,438s
Enter fullscreen mode Exit fullscreen mode

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",
    },
  },
  ...
];
Enter fullscreen mode Exit fullscreen mode

The time output:

real    0m14,622s
user    0m48,990s
sys     0m0,877s
Enter fullscreen mode Exit fullscreen mode

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",
+    },
+  },
 };
Enter fullscreen mode Exit fullscreen mode

Build times:

real    0m3,074s
user    0m5,724s
sys     0m0,161s
Enter fullscreen mode Exit fullscreen mode

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",
+      },
+    },
   },
...
Enter fullscreen mode Exit fullscreen mode

time output:

real    0m14,904s
user    0m48,754s
sys     0m1,154s
Enter fullscreen mode Exit fullscreen mode

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)

Collapse
 
pavelloz profile image
Paweł Kowalski

Nice research :)

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

Collapse
 
marcinwosinek profile image
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.