Jay
Jay CTO and Co-Founder of Trellis.org, Angular GDE and open source contributor.

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

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:

Stat large medium1 medium2 small
Number of Libraries 400 323 250 70
Lazy Loaded Chunks 98 52 27 11

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.

Version large medium1 medium2 small
v11 6.08 4.96 3.47 1.92
v12 5.97 4.72 3.43 1.92

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

Command large medium1 medium2 small
v11 `build` 359.182 233.536 138.212 109.851
v11 `build` (no aot) 216.970 121.133 87.063 56.726
v12 `build` 350.488 236.748 160.011 137.307
v12 `build` w/ webpack cache 314.366 251.175 160.430 95,080
v12 `build` (no aot) 264.419 164.174 112.823 134.187
v12 `build` (no aot) - w/ webpack cache 219.058 160.323 113.743 82.720

ng serve

  • The small and large in the first column determine how “big” of a change was made. See above for explanation.
Command large medium1 medium2 small
v11 serve 135.573 100.668 60.852 34.609
v11 serve (no aot) 94.762 70.415 50.235 64.678
v12 serve 215.846 172.057 117.094 90.813
v12 serve (no aot) 144.112 123.583 85.858 82.614
v11 reload - small 9.969 12.993 8.073 2.312
v11 reload (no aot) - small 9310 8195 5194 10782
v11 reload - large 28.928 23.758 13.593 9.806
v11 reload (no aot) - large 25.792 19.165 11.815 11.508
v12 reload - small 49.881 44.062 37.193 21.538
v12 reload (no aot) - small 36.102 33.669 26.461 19.530
v12 reload - large 45.140 63.218 17.789 14.888
v12 reload (no aot) - large 35.907 28.544 16.931 10.246