iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Use eager loading for routes that should be ready immediately, lazy loading to keep secondary route code out of the initial bundle, and preloading when you want to fetch selected lazy routes in the background after startup. The right choice depends on which pages people visit, how much startup JavaScript the app ships, and whether background downloads are acceptable.
How Angular route loading strategies differ
Route loading controls when the browser downloads JavaScript for route components and child route configuration. It is separate from whether Angular renders HTML on the client, at build time, or on the server.
| Strategy | Initial transfer | First visit to a deferred route | Background cost | Good starting point |
|---|---|---|---|---|
Eager component (component) |
Route component code is included with the route configuration bundle. | No separate route-code fetch is needed for that component. | Less deferred-fetch overhead. | Primary landing pages or small apps where immediate availability matters. |
Lazy component (loadComponent) |
Component code is deferred to a chunk. | A fetch may occur when the route becomes active. | Code is requested when the route is used. | Secondary or infrequently visited pages. |
Lazy child routes (loadChildren) |
Child route configuration is deferred. | The router loads it during route matching. | Useful for route groups; unnecessary nested deferral can add latency. | Feature areas with their own route configuration. |
| No preloading | Lazy chunks stay deferred until navigation. | The user may wait for the first request. | Lowest background prefetch use. | Default policy, bandwidth-sensitive apps, or rarely visited areas. |
| Preload all | Lazy modules begin loading after initial navigation. | Can reduce the wait once a chunk has loaded. | Uses bandwidth and memory and may compete with other work. | Smaller apps where fetching all lazy modules is acceptable. |
| Selective preloading | Only opted-in lazy routes are prefetched. | Can help on routes selected for preloading. | Balances first-visit delay against background cost. | Apps with known navigation patterns or route metadata. |
When to choose eager or lazy routes
Keep important entry routes eager
An eager route uses component. Angular includes the referenced component with the route configuration bundle, so its code is available without a separate route-code request when the user navigates there. The trade-off is a larger initial bundle that the browser must download and parse. Angular suggests eager-loading primary landing pages as a general starting point, not a universal rule. Angular’s route loading guide explains the trade-off.
Lazy-load secondary pages or feature areas
Use loadComponent when an individual route component should be loaded on demand, or loadChildren when a set of child routes should be deferred. Both accept loader functions returning promises; dynamic import() is the common pattern, and the build typically emits separate chunks that are fetched when needed. A lazy route can reduce initial transfer, but its first visit may incur a network request and delay. Avoid adding layers of lazy loading without a reason: deeply nested deferral can add latency.
#1 Best Overall
For example, a primary dashboard route can be eager while an infrequently opened reporting area is lazy:
import { Routes } from '@angular/router';
export const routes: Routes = [
{
path: 'dashboard',
component: DashboardComponent,
},
{
path: 'reports',
loadComponent: () =>
import('./reports/reports.component').then(m => m.ReportsComponent),
},
];The exact import path and component names depend on the application. In a standalone route configuration, the loader function is where the deferred import is declared; Angular’s Route API documents these route properties.
How to configure lazy loading
- Choose the deferral boundary. Use
loadComponentfor one route component, orloadChildrenfor child route configuration that belongs to a feature. - Replace the eager reference with a loader. Use a promise-returning function, commonly a dynamic import, that resolves to the component or routes.
- Build and inspect the result. Confirm that the intended code is split into a separate chunk and check navigation behavior in the built application; the improvement depends on the app and its usage.
Angular runs route loader functions in the route’s injection context. That allows inject to access providers available to the route and its parent hierarchy, which can support route-dependent choices such as selecting an implementation from a feature flag. Keep such decisions clear: conditional loader logic should not obscure which code is deferred or when it is requested. See Angular’s route loading guide.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Should you preload lazy routes?
Preloading starts requests for lazy routes in the background after navigation, so a user may encounter less delay when first opening a prefetched route. Angular’s default, NoPreloading, does not preload. PreloadAllModules starts loading lazy modules after initial navigation. Preloading does not make the code free: it consumes bandwidth and memory, and its requests may compete with images, API calls, or other critical work. Consider likely navigation, network conditions, and device constraints.
Rank #3
Preload every lazy module
Configure the router with PreloadAllModules when fetching all lazy modules after initial navigation is acceptable:
import { provideRouter, withPreloading, PreloadAllModules } from '@angular/router';
provideRouter(routes, withPreloading(PreloadAllModules));This is a policy choice, not a guarantee that every user benefits. It may be appropriate for a smaller app with a relatively compact set of lazy areas; it is less suitable when background traffic or memory use is a concern. See Angular’s customizing route behavior guide and withPreloading API.
Preload only selected routes
A custom PreloadingStrategy can inspect route metadata and invoke the supplied loader only for routes marked for preloading. For example, mark selected routes with data: { preload: true } and have the strategy load only those routes. This is useful when the app’s navigation patterns are known, because it can prioritize likely destinations without fetching every lazy area. Angular’s guide shows the metadata-based approach in Customizing route behavior.
Recommended Free Tools
The router’s RouterPreloader works in the background and checks after navigation events whether lazy route configurations can be loaded. Its API page states that a route guarded by canLoad is not preloaded; guard behavior can evolve, so verify the relevant API documentation for the Angular version in use. See RouterPreloader.
How to choose for your application
- Prioritize fast route availability: keep a route eager if it is central to entry and the added initial JavaScript is acceptable.
- Reduce initial route code: lazy-load secondary screens or cohesive feature areas that users do not always need.
- Reduce first-visit waits selectively: preload routes users are likely to open, while accounting for background network and memory use.
- Keep the policy simple: use no preloading when lazy areas are rare or resources are constrained; use preload-all only when its wider background cost is acceptable.
- Measure the actual app: compare build output and navigation behavior on representative devices and networks. Angular’s documentation provides qualitative guidance, not a universal percentage improvement.
Eligible eager component routes can be converted with Angular’s migration schematic, ng generate @angular/core:route-lazy-loading. Treat it as a migration aid: inspect the generated route configuration and verify application behavior. Details are in Migration to lazy-loaded routes.
Route loading is not the same as rendering mode
CSR, SSG (prerendering), and SSR describe where and when HTML is rendered. Route loading describes when JavaScript for routes is delivered. They are related architecture decisions, but one does not replace the other. Angular’s rendering strategies guide describes client rendering, build-time prerendering, and server rendering; in the described SSR and SSG setup, subsequent route changes happen client-side after hydration.
Choose rendering mode based on needs such as initial content, search visibility, interactivity, server requirements, and freshness. Choose route loading based on initial JavaScript transfer, the wait on first navigation, and the network and memory cost of deferred or prefetched code.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
