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

[amakhrov]

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)

[alan-agius4]

Hey @amakhrov, diagnosing the root cause of the LCP and FCP increase is challenging without a reproduction.

Esbuild's generation of numerous chunks is intrinsic to its design, driven by internal algorithms. Unlike webpack, chunk control isn't currently possible. Check out evanw/esbuild#207 and evanw/esbuild#1128 for more context.

Regarding the size increase, a 400kb uncompressed JS file is substantial, given JS's parsing complexity. Unfortunately, pinpointing the cause and suggesting improvements necessitates a minimal reproduction.

[alan-agius4]

Closing as per above. If the problem persist please open a new issue and provide a minimal reproduction.

[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.}