Lazy loading is one of the highest-leverage performance techniques in Angular. Done well, it can cut your initial bundle by 40–60%, dramatically improve Time to Interactive, and make your app feel fast even as it grows. Done poorly, it becomes a source of subtle bugs, missed splits, and false confidence.
This guide covers everything, from the fundamentals of route-level splitting to @defer blocks, preloading strategies, and bundle auditing, using the patterns that work in Angular 17+ with standalone components.
What is lazy loading and why it matters
When Angular compiles your app, it bundles everything into JavaScript chunks. Without lazy loading, every component, service, and library ships in one initial bundle. The browser must download, parse, and execute all of it before the user sees anything interactive.
Lazy loading breaks the app into smaller chunks that are fetched on demand , when the user navigates to a route, or when a UI element enters the viewport. The browser only pays for what the user actually needs.
The numbers matter. A 1-second improvement in load time improves conversion rates by roughly 2–5% on average. For mobile users on slower connections, the impact is even larger.
Route-level splitting: NgModule vs standalone components
Route-level lazy loading is the most impactful place to start. It ensures that each feature of your app ships its own bundle, loaded only when the user navigates there.
The old NgModule approach
Historically, Angular lazy loading required a dedicated NgModule per feature:
const routes: Routes = [
{
path: 'dashboard',
loadChildren: () =>
import('./dashboard/dashboard.module').then(m => m.DashboardModule)
}
];
This worked, but it added ceremony. Every feature needed a module wrapper purely to enable lazy loading, even when the module served no other purpose.
The modern standalone approach
Angular 14+ introduced loadComponent, and since Angular 17 all new projects scaffold as standalone by default. You can lazy load a component directly — no module required:
const routes: Routes = [
{
path: 'dashboard',
loadComponent: () =>
import('./dashboard/dashboard.component').then(c => c.DashboardComponent)
}
];
For feature areas with multiple routes, use loadChildren with a standalone routes array instead of a module:
const routes: Routes = [
{
path: 'settings',
loadChildren: () =>
import('./settings/settings.routes').then(r => r.SETTINGS_ROUTES)
}
];
Where settings.routes.ts exports a plain routes array:
export const SETTINGS_ROUTES: Routes = [
{ path: '', component: SettingsLayoutComponent },
{ path: 'profile', loadComponent: () => import('./profile/profile.component').then(c => c.ProfileComponent) },
{ path: 'billing', loadComponent: () => import('./billing/billing.component').then(c => c.BillingComponent) }
];
This pattern is cleaner, more tree-shakeable, and gives the bundle analyser a clearer picture of what belongs to each feature.
Configuring lazy routes with the Angular router
A few router options are worth understanding when working with lazy routes.
Preloading strategy
By default, Angular loads lazy chunks only when the user navigates to them. You can instruct the router to preload chunks in the background after the initial load:
bootstrapApplication(AppComponent, {
providers: [
provideRouter(
routes,
withPreloading(PreloadAllModules)
)
]
});
PreloadAllModules preloads every lazy chunk after the initial bundle is stable. This is a reasonable default for most apps. For more control, write a custom preloading strategy (covered below).
Router initial navigation
Set withRouterConfig({ initialNavigation: 'enabledBlocking' }) when using SSR to ensure the first navigation completes before the app hands off to the client. Without it, you can get a flash of blank content during hydration.
@defer blocks: sub-route and UI-level lazy loading
@defer was introduced in Angular 17 and is one of the most significant performance primitives Angular has ever shipped. It brings lazy loading down to the template level — individual UI blocks can be deferred independently of routing.
Basic usage
@defer (on viewport) {
<app-heavy-chart [data]="chartData" />
} @placeholder {
<div class="chart-skeleton"></div>
} @loading (minimum 300ms) {
<app-spinner />
} @error {
<p>Failed to load chart.</p>
}
Angular automatically code-splits the app-heavy-chart component into its own chunk. The chunk is not fetched until the trigger fires.
Built-in triggers
| Trigger | When it fires |
|---|---|
on viewport | Element enters the visible viewport |
on idle | Browser reports an idle period |
on interaction | User clicks or focuses the element |
on timer(2s) | After a fixed delay |
on immediate | As soon as possible after render |
when condition | When a signal or expression becomes truthy |
Practical patterns
Defer below-the-fold sections. If a page has a hero section and then analytics charts, defer everything below the fold with on viewport. Users see the hero instantly; charts load as they scroll.
Defer dialog content. A dialog component and all its dependencies do not need to be in the initial bundle. Wrap the dialog content in @defer (when dialogOpen()) where dialogOpen is a signal.
Combine with signals for on-demand loading:
protected showEditor = signal(false);
<button (click)="showEditor.set(true)">Open editor</button>
@defer (when showEditor()) {
<app-rich-text-editor />
}
The editor bundle is not fetched until the user explicitly asks for it.
Preloading strategies: PreloadAllModules vs custom
PreloadAllModules is convenient but blunt — it preloads everything regardless of whether the user is likely to visit those routes. For large apps, a custom strategy that preloads based on user behaviour or route metadata is worth the investment.
Custom preloading strategy
@Injectable({ providedIn: 'root' })
export class SelectivePreloadingStrategy implements PreloadingStrategy {
preload(route: Route, load: () => Observable<unknown>): Observable<unknown> {
return route.data?.['preload'] === true ? load() : of(null);
}
}
Mark routes you want preloaded:
{
path: 'reports',
loadChildren: () => import('./reports/reports.routes').then(r => r.REPORTS_ROUTES),
data: { preload: true }
}
Register the strategy:
provideRouter(routes, withPreloading(SelectivePreloadingStrategy))
This gives you per-route control. Preload the routes users commonly visit next; leave the rest on-demand.
Analysing bundle splits with Angular DevTools
Writing lazy routes is only half the job. You need to verify that splits are actually happening and identify what is inside each chunk.
Angular DevTools network tab
Install the Angular DevTools browser extension. Open DevTools, navigate to the Angular panel, and watch the network tab as you navigate. Each lazy route should produce a separate network request for a JavaScript chunk.
If a route you expected to be lazy loads as part of the initial bundle, the most common cause is a direct import somewhere in your eagerly loaded code. A single stray import { FeatureComponent } in an eager component will pull the entire feature into the main bundle.
Source map explorer
After building with source maps enabled, source-map-explorer gives you a visual treemap of every bundle:
npm run build -- --source-map
npx source-map-explorer dist/app/browser/*.js
Look for:
- Unexpectedly large chunks
- Third-party libraries appearing in feature chunks instead of the shared vendor chunk
- Components appearing in the wrong bundle
Bundle budgets
Set hard limits in angular.json to catch regressions in CI:
"budgets": [
{
"type": "initial",
"maximumWarning": "400kb",
"maximumError": "500kb"
},
{
"type": "anyComponentStyle",
"maximumWarning": "4kb",
"maximumError": "8kb"
}
]
When a budget is exceeded, the build fails. This is the safest way to prevent bundle regressions from sneaking into production.
Real-world case study: 40% bundle reduction walkthrough
Here is a typical audit pattern from a mid-size Angular app that was not using lazy loading strategically.
Starting state:
- Initial bundle: 820 kb (gzipped)
- All routes eagerly loaded
- Angular Material imported via a shared
MaterialModule
lodashimported asimport _ from 'lodash'
Step 1: Lazy load all feature routes (saved 210 kb)
The admin panel, reports section, and settings area were all loading eagerly. Converting them to loadChildren with standalone routes arrays removed 210 kb from the initial bundle.
Step 2: Switch to lodash-es with tree shaking (saved 65 kb)
Replacing import _ from 'lodash' with individual imports from lodash-es reduced the bundle by 65 kb. The standard lodash build is not tree-shakeable; lodash-es is.
Step 3: Replace MaterialModule with per-component imports (saved 48 kb)
A shared MaterialModule re-exported every Angular Material module. Switching to per-component imports so each component only imported the Material modules it actually needed removed 48 kb.
Step 4: Defer analytics and charts (saved 95 kb from initial)
Three Chart.js-powered components on the dashboard were moved into @defer (on viewport) blocks. The Chart.js library moved out of the initial bundle entirely.
Final initial bundle: 402 kb — a 51% reduction, achieved through incremental audit steps over two days.
Checklist: auditing your app's lazy loading
Use this as a starting point for your own audit:
Routes
- [ ] Every major feature area uses
loadChildrenorloadComponent
- [ ] No stray direct imports of lazy components in eager code
- [ ] Lazy chunks are visible in the DevTools network panel on navigation
@defer
- [ ] Heavy components (charts, editors, maps) are wrapped in
@defer
- [ ] Below-the-fold sections use
on viewporttrigger - [ ] Dialog and modal content is deferred until opened
Dependencies
- [ ]
lodashreplaced withlodash-esor individual function imports - [ ]
moment.jsreplaced withdate-fnsor nativeIntl
- [ ] Icon libraries use individual SVG imports, not full icon sets
- [ ] Angular Material uses per-component imports, not a shared module
Build config
- [ ] Bundle budgets set in
angular.json
- [ ] Source map explorer run and reviewed
- [ ] CI pipeline fails on budget violations
Preloading
- [ ] A preloading strategy is configured
- [ ] High-traffic routes are preloaded; low-traffic routes are not
Summary
Lazy loading in Angular in 2026 is more capable and more ergonomic than it has ever been. The combination of standalone loadComponent, @defer blocks, and the esbuild-based build pipeline gives you fine-grained control over exactly what ships in each chunk.
The key mindset shift is treating bundle size as a metric you actively monitor, not a side effect you occasionally think about. Set budgets, run source-map-explorer monthly, and treat an unexpectedly growing initial bundle as a bug worth fixing.
Found this useful? Follow Abdul-Rashid for more mid-to-expert Angular content every week. Next up: a deep dive into @defer triggers and combining them with Angular Signals for on-demand UI loading.
SOCIAL SHARE CARD GENERATOR