Comparing Angular v11 (Webpack 4) to Angular v12 (Webpack 5) build performance and size

Recently Angular v12 was released, and with it Webpack 5 under the hood of the Angular CLI/Compiler. With it came a lot of improvements, some of which are live in v12 and some are planned to be released in future version, ie. the ground work has been laid.

This is a comparison of v11 (Webpack 4) to v12 (Webpack 5) using real world example. Each app here is within the Trellis codebase. If some benchmarks are missing or seem off please feel free to tweet at @jaycooperbell and I will see what I can do about investigating and fixing them!

For obvious reasons I cannot share the actual codebase these benchmarks and metrics were measured from, but I can share the configurations and setups.

Configurations

These benchmarks are a combination of Angular version, AOT enabled/disabled, ng serve, ng build, serve reload with small and large changes, build with and without webpack cache.

Each of the builds was run using the following configuration (unless otherwise specified). Note: aot: false assumes buildOptimizer: false.

1. vendorChunk: true
2. optimization: true
3. buildOptimizer: true
4. aot: true
5. node --max_old_space_size=4096 - set for all commands so we do not run into javascript max heap errors

The serve configurations do not run with optimization: true as the Webpack dev server usually encounters a memory issue.

In the following tables the following can be assumed:

1. A small change is either adding a duplicate BrowserAnimationsModule to the AppModule of the app or removing the duplicate. This may not be incredibly scientific, but it won't actually change the bundle size or compilation process in any meaningful way.

2. A large change for all but the small app is adding a property to an interface that is throughout the application.

3. The node_modules/.cache is cleared in between all build and serve runs as to ensure webpack was doing a clean build each time.

We will be looking at 4 different Angular apps today, we will refer to them as large, medium1, medium2 and small . They have the following setup:

Size

I did not think we needed to go in deep on bundle sizes with/without aot and optimization etc because in v12 production mode is enabled by default, so the following table is just a normal prod build with all optimizations enabled. All measurements are in megabytes (MB) and taken from the "parsed size" by using webpack-bundle-analyzer.

Build Speed

• All speeds are measured in seconds
• All benchmarks were run on a Macbook Pro 2.3GHz i9 with 16GB of RAM.

ng build

ng serve

• The small and large in the first column determine how "big" of a change was made. See above for explanation.