esbuild `application` builder is significantly slower than webpack with many locales

[shamoon]

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

compiler

Is this a regression?

No

Description

Just as an aside I wanted to say thank you to the team for Angular, I have loved developing with it for years now. ❤️

With the release of v22 I took the opportunity to try and migrate paperless-ngx from the webpack builder to Angular’s recommended esbuild application builder. Unfortunately we've found that while single-locale builds are faster, our full production build on ci with 37 locales is now roughly 2–3x slower. The GHA jobs below are for an isolated change ( paperless-ngx/paperless-ngx@dev...chore/ditch-webpack ).

Builder	Build time
@angular-builders/custom-webpack:browser / webpack	56 seconds
@angular/build:application / esbuild	2 minutes 40 seconds

It seems like the slowdown is specifically associated with localization:

Application-builder build	Time
en-US only	approximately 10–15 seconds
37 locales	approximately 104 seconds

Please let me know if I can provide more detail, apologies if I missed anything here. Again thank you for all the work!

Please provide a link to a minimal reproduction of the bug

The complete GitHub Actions jobs are publicly available:

• Webpack:
  https://github.com/paperless-ngx/paperless-ngx/actions/runs/29115024618/job/86437034004

main.js             | main          |   2.87 MB |               600.74 kB
styles.css          | styles        | 268.04 kB |                27.95 kB
runtime.js          | runtime       |   1.63 kB |               815 bytes
polyfills.js        | polyfills     | 119 bytes |                92 bytes

                    | Initial total |   3.14 MB |               629.60 kB

Build at: 2026-07-10T18:40:11.982Z - Hash: 640fa143d26b075a - Time: 49907ms

• Application builder:
  https://github.com/paperless-ngx/paperless-ngx/actions/runs/29120601204/job/86500184793

✔ Building...
Initial chunk files | Names         |  Raw size | Estimated transfer size
main.js             | main          |   2.87 MB |               601.50 kB
styles.css          | styles        | 274.74 kB |                28.07 kB
polyfills.js        | polyfills     |  83.44 kB |                13.20 kB
                    | Initial total |   3.22 MB |               642.76 kB
Application bundle generation complete. [157.631 seconds] - 2026-07-11T02:15:17.228Z

Please provide the exception or error you saw

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

Angular CLI       : 22.0.5
Angular           : 22.0.5
Node.js           : 22.23.1
Package Manager   : pnpm 10.26.0
Operating System  : darwin arm64

Package                    Installed Version
------------------------------------------------
@angular-devkit/core       22.0.5
@angular-devkit/schematics 22.0.5
@angular/build             22.0.5
@angular/cdk               22.0.3
@angular/cli               22.0.5
@angular/common            22.0.5
@angular/compiler          22.0.5
@angular/compiler-cli      22.0.5
@angular/core              22.0.5
@angular/forms             22.0.5
@angular/localize          22.0.5
@angular/platform-browser  22.0.5
@angular/router            22.0.5
rxjs                       7.8.2
typescript                 6.0.3

Anything else?

The GitHub Actions comparison uses ubuntu-24.04, Node.js 24.x, and pnpm 10. The same behavior is reproducible locally on macOS arm64 with Node.js 22.23.1.

The application has 37 configured locales and an optimized initial bundle of approximately 3.22 MB. The production configuration uses localize: true and optimization: true.

Also worth noting the application-builder output is totally correct. This report is just about the build-time.

I searched existing issues before filing. I found general application-builder performance reports e.g. https://github.com/angular/angular-cli/issues/31449, but none that seemed specific to scaling with a large number of locales.

Also, suppressing missing-translation warnings with --i18n-missing-translation=ignore did not improve the result.