Angular @defer Is Not Just Lazy Loading — It’s a Rendering Strategy

Most Angular developers think lazy loading means lazy loading routes. But Angular introduced something much more powerful in recent versions:

**@defer — lazy load parts of your template, not just routes.**

And this changes how we think about performance in Angular applications.

The Problem

In many Angular apps, we accidentally load too much at once:

• Charts
• Tables
• Comments
• Recommendation panels
• Heavy components
• Third-party libraries

But users don’t see everything when the page loads. So why load everything immediately?

This is where @defer becomes very powerful.

What @defer Really Does

@defer allows you to delay loading a part of the UI until a specific condition is met.

Simple example:

@defer (on viewport) {
  <heavy-component />
} @placeholder {
  <p>Loading when visible...</p>
}

This means the component will only load when the element becomes visible on screen, not when the page loads.

This alone can significantly improve:

• LCP (Largest Contentful Paint)
• TTI (Time to Interactive)
• Initial bundle size
• User experience

All @defer Triggers Explained

Angular provides multiple triggers, and each one is useful in different scenarios:

TriggerWhen it loadsUse caseon idleWhen browser is freeNon-critical UIon viewportWhen element becomes visible on screenBelow-the-fold contenton interactionWhen user clicks/typesDialogs, tabson hoverWhen user hoversMenus, previewson immediateRight after first render (non-blocking)Medium priority UIon timer(x)After a delayAds, popupswhen conditionWhen condition is trueAfter data loadsprefetchDownload early, render laterImprove perceived performance

This is why I don’t think @defer is just lazy loading.

It’s a rendering strategy.

Built-in UI States (Very Important)

Another powerful feature of @defer is built-in states:

@defer (on interaction) {
  <heavy-component />
} @placeholder {
  <p>Click to load</p>
} @loading {
  <p>Loading...</p>
} @error {
  <p>Failed to load</p>
}

You automatically get:

• Placeholder state
• Loading state
• Error state

No extra logic needed.

One important note:

*@error only triggers when the lazy loading fails, NOT when the component itself throws an error.*

This is a subtle but important detail.

Real World Use Cases

Here are some practical examples where @defer makes a big difference:

ComponentTriggerCommentson viewportChartson viewportDialogon interactionDropdown menuon hoverRecommendationson idleAnalytics panelon immediateAdson timer(3000)After API loadwhen dataLoaded

If you apply this correctly, your app will feel much faster without changing your backend or business logic.

Final Thoughts

Before, we had:

• Eager loading
• Route lazy loading

Now, with @defer, we have:

• Component-level lazy loading
• Control over when rendering happens
• Built-in loading states
• Better performance with less effort

So the mindset changes from:

“How do I lazy load this route?”

to:

“When should this UI be rendered?”

That’s a big shift.

I Built a Visual Demo

I created a small demo that shows all @defer triggers and states visually:

• idle
• viewport
• interaction
• hover
• immediate
• timer
• prefetch
• when
• placeholder / loading / error

It’s much easier to understand when you can see when each component loads.

If you’re interested, you can find the demo at the link below.

https://stackblitz.com/edit/q-angular-defer-example

Conclusion

@defer is not just a new syntax.

It’s a new way to think about performance and rendering in Angular.

And I believe this will become a standard pattern in modern Angular applications.

If you’re working with Angular, this is definitely a feature worth exploring.