Angular zoneless: what really changes in change detection

Written by Davide Ferraretto

With recent versions, Angular offers the option to remove Zone.js and switch to zoneless change detection. It's the default I chose for this very site, and generally for the more recent Angular projects I build: it's worth understanding what really changes, not just in terms of performance but of development habits.

What Zone.js used to do

Zone.js intercepts asynchronous events (clicks, timers, HTTP requests) and automatically triggers a change detection cycle across the whole application. Convenient, but also expensive: every event, even one irrelevant to the UI, can trigger a check across entire component trees, and it's one of the most common causes of Angular apps feeling slow.

What changes in zoneless mode

Without Zone.js, Angular no longer automatically knows when a component needs to be re-rendered: it needs an explicit model, based on Signals and reactive input binding, to be notified of state changes. Asynchronous operations that manually update state (e.g. plain RxJS subscriptions not backed by signals) must be handled carefully, often with a simple ChangeDetectorRef.markForCheck() or by converting state into signals.

When it's worth adopting

Zoneless pays off especially in new applications, where state can be designed around Signals from the start, and in projects where perceived performance is a requirement, not a nice-to-have. In a legacy project with a lot of plain RxJS-based code, migration should be evaluated more cautiously and may be worth doing incrementally.

Zoneless isn't just a flag to flip: it's a shift in mindset around state management. In the projects I build from scratch I now adopt it by default, because the resulting code is more explicit about when and why the UI updates — a benefit that goes beyond raw performance.