DEV Community: Abdul Rashid

Complete guide to Angular lazy loading in 2026

Abdul Rashid — Thu, 02 Jul 2026 11:35:18 +0000

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 }
}

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
lodash imported as import _ 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 loadChildren or loadComponent
[ ] 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 viewport trigger
[ ] Dialog and modal content is deferred until opened

Dependencies

[ ] lodash replaced with lodash-es or individual function imports
[ ] moment.js replaced with date-fns or native Intl
[ ] 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.

The Immortal Hack: Architecting Around ::ng-deep in Enterprise Angular Applications

Abdul Rashid — Wed, 17 Jun 2026 10:37:55 +0000

Abdul Rashid

Jun 17

The Undead Selector: Why ::ng-deep Refuses to Die in Modern Angular

#angular #webdev #stylesheet #modernangular

5 min read

The Undead Selector: Why ::ng-deep Refuses to Die in Modern Angular

Abdul Rashid — Wed, 17 Jun 2026 10:36:40 +0000

Style encapsulation is a core feature of Angular. It gives us the peace of mind that our component styles will not leak out and ruin the rest of the application. But what happens when you need to pierce that shield? For years, developers used ::ng-deep while feeling a pang of guilt because of the "deprecated" label next to it in the documentation.
Then, Angular v18 arrived, and the framework team did something unexpected: they officially removed the deprecated status of ::ng-deep.

This article explores the technical reality behind this decision, how the selector works at the compiler level, and the architectural design patterns you should use instead.

1. The "Un-Deprecation" Event

In early 2024, the Angular team accepted GitHub Pull Request #54219. This PR altered the official Angular Styling Guide to remove all references to the deprecation of ::ng-deep. Instead, the text was rewritten to state that the API remains active exclusively for backwards compatibility.

//Old Docs Warning:
"::ng-deep is deprecated and will be removed in a future version."

//New Docs Reality:
"The Angular team strongly discourages new use of ::ng-deep.
These APIs remain exclusively for backwards compatibility."

Why Did Angular Change Its Mind?

The history of this selector comes down to web standards:

The Original Plan: When Angular v4.3 introduced ::ng-deep, it was meant as a temporary patch. The W3C was working on native shadow-piercing CSS specifications like /deep/ and >>>.
The Spec Failure: Browser vendors completely dropped those shadow-piercing specifications due to massive performance penalties.
The Pragmatic Choice: Because the browser standards failed to deliver a native replacement, Angular developers had no clean way to style internal pieces of third-party user interface libraries (like Angular Material).

The Angular team chose pragmatism over ideology. They acknowledged that removing the selector would completely break thousands of enterprise applications.

2. Under the Hood: How the Compiler Processes ::ng-deep

To understand the risk of ::ng-deep, you must understand what the Angular template compiler does with your CSS files.
By default, Angular uses Emulated View Encapsulation. The compiler modifies your HTML elements and CSS selectors by appending a unique host attribute id.

The Component Code

Imagine you write a component stylesheet targeting an item inside a child component:

The Compiled Output

The Angular compiler turns that code into highly specific CSS:

Because the .mat-select element inside the third-party library does not have that specific _ngcontent-c10 attribute on it, the style fails to apply.

Enter the Shadow Piercer

When you append ::ng-deep, it acts as a special instruction to the CSS parser. It tells the compiler: "Stop appending attribute identifiers to anything after this token."

The compiler evaluates this rule and outputs:

Now, any .mat-select that sits inside .custom-panel will get the style change, regardless of what component owns that HTML structure.

3. The Architectural Risks of Style Bleeding

The mechanics of the compiler show why using ::ng-deep carelessly introduces major bugs. Look closely at what happens if you forget to scope your selector:

The compiler removes the scope completely and outputs:

This is now a pure global style rule.

When this component renders on your page, Angular appends this style tag directly into the element of the document.
If a user navigates away from this component to another section of the application, the style tag remains in the DOM.
Every single dropdown component across your entire application turns ghostwhite, destroying your global style system.

4. Modern Alternatives

Senior developers should avoid using ::ng-deep for internal application components. Modern layout design offers cleaner patterns to bypass encapsulation boundaries.

Option A: CSS Custom Properties (The Gold Standard)

CSS custom properties (variables) pass straight through emulated view encapsulation boundaries effortlessly. If you control the child component, design it to receive configuration variables from its parent components.

Now, the parent component can cleanly re-theme the child component without piercing the encapsulation wall:

Option B: Angular Material Design Tokens

Modern UI libraries like Angular Material have abandoned deep CSS classes in favor of the W3C Design Tokens Community Group specification. Instead of overriding .mat-mdc-text-field-wrapper with a compiler hack, you provide themes directly through Sass mixins in your global stylesheets:

// styles.scss@use '@angular/material' as mat;

html {
  @include mat.theme-overrides((
    primary: mat.define-palette(mat.$blue-palette),
  ));
}

Option C: Explicit Global Stylesheets

If you must write a global style rule to target a dynamic overlay panel (like a modal popup backdrop), do not bury it inside a component CSS file. Place it inside your main styles.scss array or a dedicated overrides.scss module. This ensures that your global overrides stay highly visible and well-organized in one central place.

5. Strict Rules for Using ::ng-deep

If you hit a legacy roadblock where you absolutely must use ::ng-deep to meet a feature deadline, follow these safety guidelines:

Always Prepend :host: Never leave ::ng-deep at the root of a selector rule. Always scope it with :host to prevent styles from bleeding out across the rest of your app.

  /* Correct Scope */
   :host ::ng-deep .third-party-widget { ... }
   /* Global Leak Danger */
   ::ng-deep .third-party-widget { ... }

Add a Technical Debt Comment: Explain exactly why the alternative approaches failed so team members can refactor it later.

 :host ::ng-deep .vendor-chart-line {
     /* TODO: Remove once vendor library supports CSS variables */
     stroke: #00ff00;
   }

Summary

The removal of the "deprecated" label from ::ng-deep in Angular v18 is not an invitation to write sloppy, unencapsulated global CSS. It is simply an acknowledgment of the technical realities of modern web development. Use it strictly as a specialized tool for targeting third-party components, and rely on CSS custom properties for your internal application layout architecture.

Reference:
Angular ng-deep
Angular Github Issues

DEV Community: Abdul Rashid

Complete guide to Angular lazy loading in 2026

What is lazy loading and why it matters

Route-level splitting: NgModule vs standalone components

The old NgModule approach

The modern standalone approach

Configuring lazy routes with the Angular router

Preloading strategy

Router initial navigation

@defer blocks: sub-route and UI-level lazy loading

Basic usage

Built-in triggers

Practical patterns

Preloading strategies: PreloadAllModules vs custom

Custom preloading strategy

Analysing bundle splits with Angular DevTools

Angular DevTools network tab

Source map explorer

Bundle budgets

Real-world case study: 40% bundle reduction walkthrough

Checklist: auditing your app's lazy loading

Summary

The Immortal Hack: Architecting Around ::ng-deep in Enterprise Angular Applications

The Undead Selector: Why ::ng-deep Refuses to Die in Modern Angular

The Undead Selector: Why ::ng-deep Refuses to Die in Modern Angular

1. The "Un-Deprecation" Event

Why Did Angular Change Its Mind?

2. Under the Hood: How the Compiler Processes ::ng-deep

The Component Code

The Compiled Output

Enter the Shadow Piercer

3. The Architectural Risks of Style Bleeding

4. Modern Alternatives

Option A: CSS Custom Properties (The Gold Standard)

Option B: Angular Material Design Tokens

Option C: Explicit Global Stylesheets

5. Strict Rules for Using ::ng-deep

Summary

`@defer` blocks: sub-route and UI-level lazy loading