Angular Change Detection and Performance: Zone.js, OnPush, and Going Zoneless

Change detection is the question every UI framework must answer: state changed — how does the screen find out? Angular has answered it three different ways across its life (zone-based check-everything, OnPush pruning, and now signal-driven precision), and real codebases contain archaeology from all three eras. Understanding the system is what separates developers who fix performance problems from those who sprinkle memoization and hope.

This guide tells the story in order — because each era explains the next — then delivers the practical playbook: what actually makes Angular apps slow and what actually fixes them.

Era One: Zone.js and the Check-Everything Model

Classic Angular’s insight: DOM updates can only be needed after something happened — a click, a timer, an HTTP response, a resolved promise. So Angular shipped zone.js, a library that monkey-patches every async API in the browser (setTimeout, listeners, promises) to notify Angular: “an event just finished — something may have changed.”

And then, the blunt part: Angular would re-check every binding in every component, top of the tree to the bottom. {{ user.name }}, [disabled]="count === 0" — each expression re-evaluated, compared to its previous value, DOM patched where different.

Judge it fairly: this design made Angular magically ergonomic — mutate any property anywhere (this.user.name = 'X') and the UI just updated, no ceremony, no setState. The cost was proportionality: every keystroke triggered a full-tree check, and a 5,000-binding app did 5,000 comparisons per event. Fine at small scale, and the source of the classic large-app symptoms: sluggish typing in forms, jank during scroll-driven events, and profiler flame charts dominated by change-detection passes.

This era also birthed the infamous ExpressionChangedAfterItHasBeenCheckedError — dev-mode Angular runs the check twice to catch bindings that changed during checking (state mutated in the wrong lifecycle moment); the error means “your rendering has a feedback loop,” and its cures (move the mutation, defer it) make sense only once you know the double-check exists.

Era Two: OnPush — Pruning the Tree

ChangeDetectionStrategy.OnPush was the optimization contract: this component only needs checking if its inputs changed (by reference), an event fired inside it, or an async pipe emitted. Otherwise, skip it — and its entire subtree:

@Component({
  selector: 'app-order-row',
  changeDetection: ChangeDetectionStrategy.OnPush,
  ...
})

A list of 500 OnPush rows re-checks only the row whose button was clicked, not all 500. The catch — and the source of a thousand “my UI stopped updating” bugs — is the by reference clause:

this.order.status = 'shipped';        // OnPush child bound to [order]: sees NOTHING
this.order = { ...this.order, status: 'shipped' };   // new reference: updates ✓

OnPush is thus inseparable from immutable update discipline — the same reference-equality contract as pure pipes and @for tracking. Teams that adopted “OnPush everywhere + immutable data” got fast Angular; teams that half-adopted got whack-a-mole staleness patched with ChangeDetectorRef.markForCheck() calls (the manual “please check me” escape hatch you’ll recognize all over legacy code, along with detectChanges() — read them as symptoms of the era’s contract being fought rather than followed).

Era Three: Signals and Zoneless — Precision

Signals inverted the question. Instead of “an event happened, what might have changed?”, the dependency graph answers “this signal changed — exactly these views read it.” No zone patching, no tree walking, no reference-comparison contract to violate: reads register dependencies, writes notify dependents, rendering updates precisely the affected views.

Which makes zone.js removable — zoneless Angular:

provideZonelessChangeDetection()

What changes in practice: change detection triggers only from signal writes, template events, and framework-known async (resources, async pipe) — not from arbitrary setTimeout mutations. Code that relied on zone magic (setTimeout(() => this.someField = x) with a plain field) stops updating the UI — which is precisely the migration checklist: state that drives templates becomes signals, and the ergonomics you already learned in this series are the zoneless-safe ones. The payoffs beyond speed: zone.js’s bundle weight and stack-trace pollution gone, fewer main-thread interceptions, and — since OnPush semantics fall out naturally when everything is signal-driven — the entire era-two contract becomes implicit.

The migration reality for working developers: new apps start zoneless-friendly by default (signals everywhere); existing apps move incrementally — OnPush + signals first (works beautifully with zones), zoneless flip when the codebase stops relying on zone triggers. All three eras coexist in the industry right now; you’ll debug all three.

The Performance Playbook

With the theory placed, the practical hierarchy — ordered by how often each is actually the problem:

1. Rendering too much, too often. The dominant cause. Fixes in order of leverage: track done right on every @for (wrong tracking = full list rebuilds — the single most common Angular perf bug); OnPush/signals so unrelated updates don’t touch heavy subtrees; @defer for below-fold weight; pagination or virtual scrolling (CDK cdk-virtual-scroll-viewport) when lists exceed a few hundred rows — the DOM should hold what’s visible, not the dataset.

2. Expensive work inside bindings. Every checked binding runs per pass in zone-era code — a sort inside a template method can run thousands of times. Fix: computeds and pure pipes so work runs on change, not on check. Symptom to hunt: any nontrivial function called from a template.

3. Update storms. High-frequency sources — scroll, resize, keystrokes, WebSocket ticks — each triggering detection. Fix: debounce/throttle at the source, batch socket updates before writing signals, and keep heavy computation off the main thread entirely (workers) when it’s genuinely heavy.

4. Bundle and startup cost — a different axis (time-to-interactive rather than runtime smoothness), owned by lazy loading and build tooling, next guide.

And the meta-rule that governs all four: profile before optimizing. Angular DevTools’ profiler shows change-detection cycles, which components consumed them, and how long — one recording usually points at the guilty list or binding. Optimizing without it is how codebases accrue memoization scar tissue in the wrong places, the same discipline as JVM tuning: measure, then cut.

A Profiling Session, Narrated

Theory lands when you’ve walked one real investigation. The setup: users report the orders page “lags when typing in the filter box.” The session:

Step 1 — reproduce and record. Angular DevTools → Profiler → record while typing five characters. The timeline shows five change-detection cycles, each ~180ms — well past the 50ms long-task threshold, so typing drops frames. Expanding one cycle: OrderRow × 800 accounts for nearly all of it.

Step 2 — form the hypothesis. 800 rows re-checked per keystroke means the list isn’t isolated from the filter’s updates. Two suspects from the playbook: no OnPush/signal isolation (item 1), or per-row template work (item 2).

Step 3 — inspect the code. The row template contains {{ formatAddress(order) }} — a method call doing string assembly, running 800× per cycle (item 2 confirmed). And the filtering happens in the parent’s template binding — @for (o of filterOrders(orders, query)) — re-filtering and re-creating the array every check, which with track o (object identity) also rebuilds rows whose objects were recreated (item 1’s cousin: identity churn).

Step 4 — apply the matched fixes. filtered = computed(() => filterOrders(this.orders(), this.query())) — the filter now runs on change, not per check, and returns stable objects between query changes; formatAddress becomes a computed on the row (or a pipe); track o.id replaces identity tracking.

Step 5 — measure again. Re-record: cycles at ~8ms, dominated by the rows whose visibility actually changed. Ship it, note the pattern in review guidelines.

The transferable part isn’t the specific fixes — it’s the sequence: measure, attribute (which components, which bindings), match to the playbook, re-measure. Every performance war story that ends badly skipped step 1 or step 5.

Frequently Asked Questions

Should I set OnPush on every component today? In signal-forward code it’s increasingly moot (signal-driven views behave OnPush-like anyway, and new-project schematics lean that way) — but on zone-era codebases, yes: OnPush-everywhere with immutable data remains the single highest-leverage setting, and it’s the compatibility bridge toward zoneless.

Does runOutsideAngular still matter? In zone-era apps, yes — it’s how you run high-frequency callbacks (animation loops, chart libraries) without triggering detection per frame, re-entering deliberately when state must update. Zoneless makes the pattern obsolete — there’s no zone to escape — which is itself a good argument for the migration.

Why does my app update correctly but feel janky anyway? Change detection being correct says nothing about cost — profile: it’s usually item 1 (list rebuilds from bad tracking) or item 2 (template-method work), occasionally layout thrash below Angular entirely.

Is ExpressionChanged... an error I fix or suppress? Fix — it’s a real feedback loop (state written during render). Typical causes: mutating state in ngAfterViewInit-era hooks or child components writing parent state during initialization. Restructure when the write happens (effects, afterNextRender, or event-driven); suppressing with detectChanges() buries the loop.

How do signals interact with the profiler story? Beautifully — precise invalidation means profiler traces show small, attributable work per update instead of monolithic tree passes; regressions become “this component re-rendered 400 times” findings rather than diffuse slowness.

The Interview Version

Change detection is the definitive senior-Angular interview topic. The compressed narrative that demonstrates depth: “Classic Angular used zone.js to patch async APIs and re-check the whole component tree after any event — ergonomic, but O(app) work per keystroke. OnPush pruned subtrees by contract: check only on input reference changes, internal events, or async emissions — which is why OnPush and immutable updates are inseparable. Signals replaced guessing with knowledge: reads register dependencies, writes notify exactly the affected views, making zone.js removable entirely — zoneless Angular. Practically, most perf problems are still list tracking, template-method work, and update storms — profile first.” Follow-ups to expect: the ExpressionChanged error (writes during render, caught by dev-mode’s double check), markForCheck vs detectChanges (schedule-for-next-pass vs run-now — and why both are era artifacts), and “why did my OnPush component not update?” (mutation kept the reference — the answer is a spread). Candidates who narrate the eras and their whys stand apart from those who recite “OnPush makes it faster.”

One boundary clarification to carry forward: change detection governs when Angular updates the DOM, not how fast the browser renders it — a perfectly optimized detection cycle can still jank on layout thrash, unbatched DOM reads, or paint-heavy CSS, which live below the framework. When the Angular profiler shows small cheap cycles but frames still drop, switch instruments: the browser Performance panel owns that layer.

Self-Check

1. Zone-era app: typing in a header search box visibly stutters a heavy dashboard below. Explain the mechanism and name two era-appropriate fixes.
2. An OnPush child bound to [user] shows a stale name after this.user.name = x in the parent. Mechanism and the two fixes (one data-side, one escape-hatch)?
3. Why does wrong track in @for cause performance problems even when the UI looks correct?
4. A zoneless migration breaks a widget that updates a plain field in a setTimeout. Why did it work before, why not now, and the fix?
5. Order these by typical real-world impact: OnPush adoption, fixing list tracking, memoizing one template function, virtual scrolling a 5,000-row table.

(Answers: every keystroke triggers full-tree checking including the dashboard’s bindings — OnPush the dashboard subtree, and/or debounce the input at source. Mutation kept the reference; OnPush compares references — replace with a spread-updated object, or markForCheck() as the legacy hatch. Identity confusion forces DOM teardown/rebuild of rows whose data “changed” only by reference — CPU and GC churn invisible as wrongness but visible as jank. Zone.js patched setTimeout and triggered detection after it; zoneless only reacts to signals/events — make the field a signal. Fixing tracking and virtual scrolling typically dwarf the others on big lists; OnPush is broad but diffuse; single-function memoization is the smallest.)

Final guide: Lazy Loading and Deployment — route-level code splitting, build budgets, SSR basics, and shipping Angular to production.