All topics
Performanceadvanced

Bundle Size Optimization Techniques

Explain concrete techniques (tree-shaking, standalone APIs, differential loading history, dependency auditing) for reducing bundle size beyond lazy loading.

Beyond lazy loading, several other concrete techniques reduce an Angular application's overall bundle size, and interviewers in senior/performance-focused roles often ask you to name several rather than relying on lazy loading alone, since it's not the only lever available and doesn't help with the code that genuinely must be in the initial bundle.

It's like packing for a trip by first laying out everything you own (the full dependency graph), then removing anything you demonstrably won't use (tree-shaking), replacing a bulky all-in-one toiletry kit with just the three items you actually need (dependency auditing), and finally compressing what's left into vacuum-sealed bags (minification) before it goes in the suitcase.

Key Concepts

1
Tree-shaking — the build tool's ability to detect and remove code that's never actually referenced — is the automatic baseline optimization, and Angular's own architecture actively supports it: providedIn: 'root' services (versus module-registered providers) and standalone components' explicit imports arrays (versus broad, catch-all NgModule exports) both give the bundler clearer, more precise visibility into what's actually used, letting it tree-shake more aggressively than the older NgModule-heavy patterns allowed.
providedIn: 'root'imports
2
Auditing third-party dependencies is a frequently underrated technique: a single unnecessarily large date/utility library, or importing an entire library when only one function from it is actually used (importing all of lodash for one function instead of lodash-es's tree-shakeable individual exports, for instance), can dominate an application's bundle size far more than any application code does — checking package.json and bundle analyzer output for oversized dependencies is a concrete, high-leverage audit step.
lodashlodash-espackage.json
3
Other worthwhile techniques include enabling and correctly configuring Angular's build optimizer/production build settings (minification, dead code elimination, which are on by default in ng build production configurations but worth confirming), avoiding polyfills for browsers you don't actually need to support, and being deliberate about CSS bundle size too — unused utility-CSS classes or unnecessarily large component style sheets contribute to overall payload size just as much as JavaScript does, even though interview discussions often focus on JS alone.
ng build