Explain Router Preloading Strategies in Angular

42 / 100

Routingadvanced

Router Preloading Strategies

Explain how preloading strategies fetch lazy-loaded chunks in the background after initial load, and the built-in options available.

Lazy loading alone means a user pays a network round-trip the first time they navigate to any given feature, which can feel like a stutter compared to an eagerly-loaded route. Preloading strategies solve this by fetching lazy-loaded chunks in the background, after the initial app has already become interactive, so that by the time the user actually navigates there, the chunk is already cached and the navigation feels instant.

NoPreloading is a shop that only unpacks a delivery box when a customer specifically asks for that item; PreloadAllModules is unpacking every box in the stockroom right after opening, whether or not anyone will buy those items today; a custom strategy is selectively unpacking only the popular items ahead of time based on what you already know customers tend to want.

Key Concepts

Angular ships two built-in strategies: NoPreloading (the default — nothing is preloaded, chunks only load on demand) and PreloadAllModules, which preloads every lazy-loaded route's chunk shortly after bootstrap, trading some unnecessary bandwidth usage (for routes the user may never visit) for uniformly fast subsequent navigations across the whole app.

NoPreloadingPreloadAllModules

For finer control than "all or nothing," you can implement a custom PreloadingStrategy — a class with a preload(route, load) method that decides, per-route, whether to call load() immediately, delay it, or skip it entirely, commonly driven by a custom data property on individual routes (e.g., data: { preload: true }) so only specific high-value routes are preloaded rather than the entire app.

PreloadingStrategypreload(route, load)load()datadata: { preload: true }

A well-rounded interview answer weighs the trade-off explicitly: PreloadAllModules is a reasonable default for small-to-medium apps where the extra bandwidth cost is negligible, but for large apps with many rarely-visited routes (or users on constrained/metered mobile connections), a selective custom strategy driven by route data or network conditions (navigator.connection, where available) is the more considered choice.

PreloadAllModulesnavigator.connection