application builder generates many initial chunks

[jnizet]

Command

build

Description

I just migrated a small project to v17 and the application builder.
The ng build command generates 13 initial (i.e. not lazy-loaded) bundles.

I don't know if it's expected or not, but if it is, I don't understand the point of having so many initial bundles (the browser builder used to generate only 3).

Won't that automatically cause performance issues, given that browsers limit the number of concurrent requests to a given domain?

Describe the solution you'd like

Unless there is a good reason (that I'm currently missing) for so many bundles, I'd like the builder to generate fewer bundles: one for the polyfills (that could be cached for a long time) and one for the application for example.

If there is a good reason for so many bundles, please enlighten me :-)

Describe alternatives you've considered

No response

[pumano]

@jnizet that how esbuild works. If you don't use http/2 it's would be drop in core web vitals. esbuild has open issue evanw/esbuild#207 but that is not implemented.

If you have http/2 setup that amount of chunks not an issue for you

[alan-agius4]

Indeed this is expected, this is becasue esbuild does cross chunk code motion which webpack does not, which results in a more smaller chunks.

When using HTTP/2 or HTTP/3 the number of files does not have any performance penalty.

[jnizet]

OK. Too bad this isn't considered.
Couldn't the CLI, which is able to know which chunks are initial and which chunks are lazy-loaded, concatenate the initial chunks generated by esbuild?

[alan-agius4]

@jnizet, containing the chunks will actually cause unnecessary code to be downloaded when navigating to a particular page.

Thus, for a performance perspective, having a lot of chunks should be better if using modern HTTP protocols. Although I do see that sometimes esbuild does generate super small chunks under 1 kb, but that is by esbuild design.

Concatenating chunks is definitely not something the Angular CLI should be doing. The bundler has the full context of how chunks should be split to download as code as possible.

[elgerm]

@alan-agius4 when you say should be better, is this tested? How does esbuild know which pages where are thus creating chunks per page as webpack builder does?

Our website shows very bad performance after upgrading to angular 17. Lighthouse reports too many chained requests (150 chunks!):

before with angular 16 it was only 3 chunks and much better perf:

[pumano]

@elgerm you are right, but check my message above, try to upgrade your http to http/2 or better http/3 to get better performance, because http 1.1 has only 6 parallel connections in browser (that IS reason why concatenation in vendor chunk exist) while http/2 has 100

[alan-agius4]

Hi @elgerm,

Which HTTP version are you using? In the case of HTTP 1 it is expected that there is a performance regression. It is also important mentioning that lighthouse should not be ran against a the local dev-server.

Esbuild performs code motion and splits the code based on it's usage which does create more chunks. This is described here: https://github.com/evanw/esbuild/blob/main/docs/architecture.md#code-splitting. Webpack has less chunks as it's unable to perform this sort of advanced optimization.

What is the lighthouse score before and now?

[elgerm]

Hi guys, Lighthouse score went down from 70ish to 39.

We're behind cloudflare and have http3 enabled.

I switched back to 16 for now as this was unacceptable performance.

We get about 50k daily unique visitors from SE Asia, 33% use old devices and may find this unusable. Hence the question if it has been tested that so many small chunks don't degrade performance. There must be a penalty from loading and bootstrapping so many small chunks?

Angular went from module based to component based and now switched to esbuild that now generates a chunk per component/directive/pipe. There's 450 chunks in the dist folder 🤯.

Is it possible to go back to webpack build w 17?

[pumano]

@elgerm its possíble to use webpack with 17 angular. Just use browser target, not browser-esbuild

[sod]

The lighthouse block Avoid chaining critical requests is unfortunate reporting. You can only pick one:

1. many chunks but less unused code
2. few chunks but more unused code

The old way (less & bigger chunks) is apparently worse as it's reported under reduce unused javascript with a real penalty.

But 152 files on initial load indeed does sound scary. Sadly esbuild has no minChunkSize setting like webpack does.

[SamanthaAdrichem]

Our system creates waay more than those 150 chunks, it's actually at 240+ initial chunks (and 472 lazy chunks).

It is a rather large platform.
We went from 58 requests at initial load to over 400

It's still fast though, but I would like the preload to be reduced/delayed.

Tbh, though Angular is made for larger systems. It often feels like the really really large systems like this are not being tested out well. (not trying to bash here, just how it feels, I still love angular and the way it works a lot)

(Though it could just be that we should set things up differently, but there isn't much documentation about building a big system)

Angular 16: (still on webpack)

Angular 17: (no longer on webpack)

[Martinspire]

Small project but a lot of dependencies that didn't combine their scripts which results in 698 chunks. I'm all for optimizing, but this is just weird. Especially seeing most are external dependencies which could very well be combined (or at least provide the option to do it). It currently serves 304 chunks for the first page of our project (most of it are external dependencies)

[pumano]

what I really recommend to all as workaround is to use webpack for production and serve app for development with --forceEsbuild=true it run your project faster for development purposes, but production code build as previously using webpack. Some problems can be potentially found with background-image resolving difference, but in other cases all works same. We use it in our large app until esbuild not provide some solution for it.

[joewIST]

This is also an issue for us. Looks like we may need to revert to using webpack for production as well, as the chaining of chunks on initial load is causing non-trivial performance issues.