Degraded Web Vitals (LCP, FCP) after switching a universal app to esbuild #27321

Which @angular/* package(s) are the source of the bug?

compiler-cli

Is this a regression?

Yes

Description

We recently (Feb 14) switched to the esbuild build, and observed increased LCP and FCP - both lab and field data. We have HTTP2 enabled at our CDN (Cloudflare). We ended up rolling back to webpack (on Mar 13).

Some charts demonstrating the impact

Lab data: LCP (desktop)
Jumped from 1.7s to 1.9s

Field data: LCP (desktop)
Jumped from 2.9s to 3.2s

Note that we only updated the browser builder (from browser to browser-esbuild), and didn't migrate the SSR part from server to application (we deferred this due to some breaking changes with the existing code).

Please provide a link to a minimal reproduction of the bug

No response

Please provide the exception or error you saw

No response

Please provide the environment you discovered this bug in (run ng version)

Angular CLI: 17.1.2
Node: 18.18.2
Package Manager: yarn 3.5.0
OS: darwin arm64

Angular: 17.1.2
... animations, cli, common, compiler, compiler-cli, core, forms
... localize, platform-browser, platform-browser-dynamic
... platform-server, router, ssr

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1701.2
@angular-devkit/build-angular   17.1.2
@angular-devkit/core            17.1.2
@angular-devkit/schematics      17.1.2
@angular/cdk                    16.1.7
@angular/material               16.1.7
@schematics/angular             17.1.2
rxjs                            7.8.1
typescript                      5.2.2
zone.js                         0.14.4

Anything else?

• It might be related to the large number of chunk files esbuild produces: 140 initial and 90 lazy-loaded. For comparison, with webpack it is 5 initial and 60 lazy-loaded.
• Total size of initial chunks with esbuild is slightly higher than with webpack: 5.5MB vs 5.1MB uncompressed.
• Compression also seems to favor fewer big chunks. Compressed (transferred) size is 1.8MB (esbuild) vs 1.5MB (webpack). It's 20% transfer size increase!

Previously, someone else also reported a drop in Lighthouse score, despite having HTTP 2: #26307 (comment)