NgZone and WebSockets: Managing Change Detection Boundaries

The short answer

Keep the WebSocket connection and message parsing outside Angular's zone, and re-enter the zone — or write to a signal — only when a message actually changes view-bound state. Do not call ChangeDetectorRef.detectChanges() per message; batch updates and let OnPush or signals localize the refresh. The ExpressionChangedAfterItHasBeenCheckedError risk disappears when updates are applied asynchronously (per frame or per interval) rather than synchronously inside a detection pass.

Why the default behavior hurts

Zone.js patches native async APIs, including WebSocket events. Every onmessage therefore schedules a change detection cycle from the root component down. At tens or hundreds of messages per second — market ticks, telemetry, cursor positions — that is a full detection run per message, which is the usual source of jank and CPU spikes in data-heavy dashboards.

Recommended pattern

1. Subscribe to the socket inside ngZone.runOutsideAngular() so message handling never schedules detection.
2. Parse, filter, and buffer messages outside the zone. Cap update frequency with bufferTime, throttleTime, or requestAnimationFrame — applying one batched update per frame is usually indistinguishable from per-message updates visually.
3. When a batched result changes view state, either re-enter with ngZone.run(() => ...) once per batch, or write to a signal / BehaviorSubject consumed via the async pipe.

this.ngZone.runOutsideAngular(() => {
  this.socket.onmessage = (e) => this.raw$.next(JSON.parse(e.data));
});

this.raw$.pipe(bufferTime(100)).subscribe(batch => {
  if (batch.length) this.ticks.set(merge(this.ticks(), batch));
});

About manual detectChanges()

If you do use ChangeDetectorRef, prefer markForCheck() plus a single scheduled detectChanges() per batch, not per message. Calling detectChanges() synchronously inside a message handler reintroduces per-message cost and is the classic way to trigger ExpressionChangedAfterItHasBeenCheckedError when the handler fires during an in-progress check. Scheduling via requestAnimationFrame or a microtask avoids this.

How signals change the picture

With signal-based change detection (Angular 17+; zoneless became stable in v20), writing to a signal marks only the consuming view dirty — no global pass, and no zone re-entry is required for the write itself. In a zoneless application there is no NgZone boundary to manage at all; the remaining concern is purely update frequency, so batching still matters. Signal semantics are version-sensitive, so confirm against your Angular version before relying on zoneless behavior.

Common failure mode

Running everything outside the zone without ever re-entering or writing a signal produces a UI that silently never updates. If your stream works in the console but the view is frozen, that is the first thing to check.

Verification

• Add a temporary counter in the root component's ngDoCheck and compare cycles per second before and after the change.
• Profile with Angular DevTools or the browser Performance panel under a simulated high-rate stream.
• Confirm state-changing updates still reach the view through zone.run() or signal writes.