Recommended Free Tools
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
Zone pollution in Angular is unnecessary change detection triggered by asynchronous work that does not change data shown in the view. Find the task causing repeated cycles with Angular DevTools, then move only view-independent work outside Angular’s zone with NgZone.runOutsideAngular. Re-enter the zone when a callback changes application state that needs to render.
What zone pollution means in Angular
Angular describes Zone.js as “a signaling mechanism that Angular uses to detect when an application state might have changed.” Zone.js tracks asynchronous operations, including timers, network requests, and event listeners. A task can prompt Angular to check for changes even when it has not changed the application data or anything displayed in a template. Those unnecessary checks are called zone pollution. Angular’s zone pollution guide explains the behavior and its common causes.
Common triggers include requestAnimationFrame, setTimeout, setInterval, and tasks or microtasks scheduled by third-party libraries. A library may install event listeners, start timers, or make XHR requests while running inside Angular’s zone; its background activity can then prompt repeated change detection even when the view has nothing to update.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How to identify the task causing extra change detection
- Open the application in Angular DevTools and use its profiler to inspect change-detection activity.
- Look for repeated activity associated with timers, animation frames, or event handlers, including
setTimeout,setInterval, andrequestAnimationFrame. - Trace the activity to the code or library that schedules it. If your own code makes only a limited number of calls to these APIs, Angular notes that a third-party library is often responsible.
- Check whether the work changes data used by the template. A profiler timeline is a clue, not proof that a task is safe to move outside the zone.
Angular recommends profiling to find performance bottlenecks; its zone-pollution guidance applies to zone-based applications where profiling shows excessive change-detection cycles. See the Angular performance overview.
#1 Best Overall
When to use NgZone.runOutsideAngular
Use runOutsideAngular when starting recurring or high-frequency asynchronous work that does not need to update Angular views. For example, a polling timer can be started outside the zone:
this.ngZone.runOutsideAngular(() => {
setInterval(pollForUpdates, 500);
});The interval shown is an example, not a recommended polling frequency. Tasks and microtasks scheduled from within the callback continue outside Angular’s zone, so they do not trigger change detection through the zone mechanism. Angular’s NgZone API documentation describes this behavior.
The same principle can apply when initializing a third-party library that registers frequent event handlers or schedules timers. Angular’s guide demonstrates initializing Plotly outside the zone; handlers registered by that initialization also run outside it. First verify that the library’s work does not need to update the view.
Re-enter Angular when a callback changes view state
If an event handler updates application state or emits an Angular output that should be reflected in the view, use NgZone.run around that update:
Rank #3
plotly.on('plotly_click', event => {
this.ngZone.run(() => {
this.plotlyClick.emit(event);
});
});Alternatively, use an explicit change-detection mechanism suited to the application’s architecture. The practical distinction is whether the asynchronous work affects what Angular needs to render: keep view-independent work outside the zone, and notify Angular when meaningful state changes.
Zone-based or zoneless? Check the Angular version first
Angular’s current performance overview says zoneless change detection is the default for new applications in Angular v21 and later. The zone-pollution remedy is therefore most directly relevant to applications that still use Zone.js for change detection. Establish your application’s version and configuration before changing code; the performance overview and zoneless guide provide version-specific context.
The zoneless guide documents an opt-in using provideZonelessChangeDetection() at bootstrap for Angular v20 applications. In zoneless mode, Angular relies on notifications such as ChangeDetectorRef.markForCheck, ComponentRef.setInput, updating a signal read by a template, and bound host or template listeners. The guide recommends OnPush as one way to help ensure components use compatible notification mechanisms, but says it is not required.
For a zoneless migration, Angular’s guide says to remove Zone.js from build polyfills and dependencies when the application is ready. NgZone.run and runOutsideAngular can remain in code compatible with zoneless applications. Removing them indiscriminately can cause regressions in libraries used by applications that still rely on Zone.js. Consult the guide for migration details that match your Angular version and application setup.
Choosing between targeted fixes and a zoneless migration
These are different remedies: a targeted fix limits unnecessary work in a zone-based app, while a zoneless migration changes how the application receives change notifications. The relevant considerations are the application’s Angular version, how much third-party code schedules asynchronous tasks, whether components use supported notifications such as signals or markForCheck, and migration, SSR, and testing compatibility. Angular’s documentation does not establish a universal performance benchmark for choosing one path over the other.
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.
