Implement vendor chunk support for esbuild builder

[pumano]

Command

build, serve

Description

When using esbuild builder, we got many chunks:

but that amount (we have around 50-65) not suitable for production use cases, because of performance application degradation due to poor web vitals. That happens due to absence of vendor chunk support. Yes we got that message, when we 'serve' app:

The esbuild-based browser application builder ('browser-esbuild') is currently in developer preview and is not yet recommended for production use. For additional information, please see https://angular.io/guide/esbuild
The 'namedChunks' option is not used by this builder and will be ignored.
The 'vendorChunk' option is not used by this builder and will be ignored.

Describe the solution you'd like

Would be good to have support of vendor chunk when all node modules libs concatenated like webpack builder do.

That dramatically changed core web vitals due to small amount of initial chunks

Describe alternatives you've considered

No response

[alan-agius4]

For context esbuild does not support this evanw/esbuild#207

[pumano]

@alan-agius4 yes, I see before that issue, but, in that case, esbuild is not suitable for production. I really test it for our large production application and see dramatic web vitals degradation. esbuild in that case only provide some speed of building, but ruin real web vitals totally. Would be good if @alan-agius4 and your team can propose changes to esbuild for vendor chunk support.

[alan-agius4]

Hi @pumano,

I did discuss this with @clydin, from initial testing we saw that with esbuild the lighthouse score were slightly better.

Overall, vendor chunking should have only been used for development purposes. This only existed in the Webpack builder to workaround rebuild time issues that Webpack has. While indeed Esbuild does generate more chunks, this does not necessary mean they are all initial, and in the majority of cases this is done to return initial size which should improve CWV as Webpack's module concatenation causes a lot of unneeded code to be put in the initial chunk.

Are you testing the lighthouse scores on a production or the Angular CLI dev-server? Testing with a dev-server can result in an incorrect scores since server config is a big part of this, such as response processing which differs greatly between vite and webpack-dev-server, compression, caching etc... It would be helpful to share your lighthouse reports.

[pumano]

@alan-agius4 I prepare lighthouse comparison for our app with webpack and with esbuild (large app with around 60 libs inside monorepo):
note: we don't use HTTP/2

before:

after:

I can provide both build links for testing if needed (privately via some type of messenger or discord)

[alan-agius4]

we don't use HTTP/2

Any reason why you don't use HTTP 2? From the screenshots above I can see that the initial requests more than doubled, from 54 to 110 requests.

I can provide both build links for testing if needed (privately via some type of messenger or discord)

It would we great if you could send them via discord. You can find me in discord.gg/angular

[pumano]

Any reason why you don't use HTTP 2? From the screenshots above I can see that the initial requests more than doubled, from 54 to 110 requests.

We have some limitations now, but after this issue we also trying to looking for HTTP/2

It would we great if you could send them via discord. You can find me in discord.gg/angular

I already sent you DM message

[alan-agius4]

Hi @pumano,

We discussed the issue that you are facing and the root cause does appear to be because of using HTTP 1.

With the new modern toolchain we recommend users using modern HTTP protocols such like HTTP/2 or HTTP/3 which nowadays are provided out of the box by the majority of hosting providers and CDNs.

In the unlikely event that you still experience poor web vitals after using HTTP/2 or 3 please open a new issue.

[pumano]

@alan-agius4 OK thank you, for detailed feedback. We will try to upgrade our infrastructure for using HTTP/2.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}