Lazy Loading for Bundle Size

Every byte of JavaScript in the initial bundle has to be downloaded, parsed, compiled, and executed by the browser before the application becomes interactive, and this cost scales with bundle size regardless of how fast the user's specific device or network connection is — a large bundle disproportionately hurts users on slower connections or lower-end devices, which is a real equity and reach concern for consumer-facing applications, not just an abstract performance number.

Lazy loading directly attacks this by ensuring the initial bundle contains only what's needed for the first meaningful paint and initial interaction, deferring everything else (admin panels, rarely-visited settings pages, entire feature areas) to be fetched only if and when the user actually navigates there — which for many real applications, where users only touch a fraction of all available routes in a typical session, can be a substantial reduction in what's downloaded for the common case.

A thorough interview answer connects this to measurement: bundle analyzer tools (like source-map-explorer or the Angular CLI's own --stats-json output feeding into webpack-bundle-analyzer) are how you actually verify lazy loading is working as intended — confirming a feature's code genuinely lives in its own separate chunk rather than being accidentally pulled into the main bundle through some eager import elsewhere in the codebase, which is a surprisingly common way lazy loading silently stops working without any error being thrown.