Change Detection & Performance

Your component holds state; its template describes the DOM in terms of that state. Change detection is the process that keeps the two in sync: Angular re-runs a component's template bindings, compares each result with the value it used last time, and touches the DOM only where something differs. It never re-creates the DOM from scratch, and it never diffs the DOM itself — it diffs the binding values.

Every change-detection system has to answer two separate questions, and keeping them apart is the key to this whole chapter:

1. When should a check run? Something has to notice that state may have changed and schedule a pass. Historically that was zone.js; in Angular 22 it's signals, events and explicit notifications (see Zoneless Angular).
2. Which components should be checked on that pass? Historically, all of them, top to bottom, every time — Rohit's notes call it "broad checking / eager". With OnPush and signals, only the ones that might have changed (see OnPush and Why signals make change detection cheaper).

To see what a "check" is, look at what the compiler turns a template into. This is the real development-build output for a small counter:

@Component({
  selector: 'app-counter',
  template: `<p>Count: {{ count() }}</p><button (click)="count.set(count() + 1)">+1</button>`,
})
export class Counter {
  count = signal(0);
}

template: function Counter_Template(rf, ctx) {
  if (rf & 1) {
    ɵɵdomElementStart(0, "p");
    ɵɵtext(1);
    ɵɵdomElementEnd();
    ɵɵdomElementStart(2, "button", 0);
    ɵɵdomListener("click", function Counter_Template_button_click_2_listener() {
      return ctx.count.set(ctx.count() + 1);
    });
    ɵɵtext(3, "+1");
    ɵɵdomElementEnd();
  }
  if (rf & 2) {
    ɵɵadvance();
    ɵɵtextInterpolate1("Count: ", ctx.count());
  }
}

Before signals, Angular had no way to know when your data changed — a plain property assignment is invisible. So it watched for the things that could change data: user events, timers, promises, HTTP responses. zone.js does that by monkey-patching the browser's async APIs (setTimeout, Promise.then, addEventListener, XMLHttpRequest/fetch and many more) so that every callback runs inside a "zone" that Angular can observe. When the zone becomes quiet — no more microtasks pending — Angular's NgZone triggers ApplicationRef.tick(), which checks the whole component tree.

The mental model: zone.js is a motion sensor on every door in the house. Any door opens — a click, a timer, a response — and the lights in every room switch on so Angular can look around. It's very convenient (you never think about it) and very wasteful (most rooms didn't change).

import { ApplicationConfig, provideBrowserGlobalErrorListeners, provideZoneChangeDetection } from '@angular/core';

export const appConfig: ApplicationConfig = {
  providers: [
    provideBrowserGlobalErrorListeners(),
    provideZoneChangeDetection({ eventCoalescing: true }),
  ],
};
// angular.json → "polyfills": ["zone.js"], and zone.js is added to package.json

Angular 22 runs without zone.js by default. The provideZonelessChangeDetection docs in core.d.ts state it plainly: "Zoneless is enabled by default in Angular v21+." New projects don't include zone.js, app.config.ts doesn't need a provider for it, and in tests TestBed.inject(NgZone) is a NoopNgZone (checked in this chapter's specs).

Without zone.js, Angular no longer guesses. Something has to tell it that a view needs updating. The same docs list exactly what does:

• ChangeDetectorRef.markForCheck() (which the async pipe calls for you)
• ComponentRef.setInput()
• updating a signal that is read in a template
• a bound host or template listener firing ((click)="…")
• attaching a view that was marked dirty, removing a view, registering a render hook

What's missing from that list is the important part: assigning a plain property from a timer, a promise or a subscription does nothing. Rohit's notes put it as "modern Angular increasingly looks like" signal-driven code, and this is why.

Each trigger was checked in a test. The components below all use Angular 22's default strategy (OnPush):

@Component({ selector: 'app-plain-default', template: `<p>{{ label }}</p>` })
class PlainDefault {
  label = 'start';
  later() {
    setTimeout(() => (this.label = 'changed'));
  }
}

it('plain property from setTimeout: no render', async () => {
  const f = TestBed.createComponent(PlainDefault);
  await f.whenStable();
  f.componentInstance.later();
  await wait(10);
  await f.whenStable();
  expect(f.componentInstance.label).toBe('changed'); // the class has the new value
  expect(text(f)).toBe('start'); // the DOM does not
});

// 1. signal set from a timer -> renders 'changed'
setTimeout(() => this.label.set('changed'));

// 2. plain property + markForCheck -> renders 'changed'
setTimeout(() => {
  this.label = 'changed';
  this.cdr.markForCheck();
});

// 3. template event -> renders 'clicked'
// template: <button (click)="label = 'clicked'">go</button>

// 4. async pipe -> renders 'from stream'
// template: <p>{{ label$ | async }}</p>
setTimeout(() => this.label$.next('from stream'));

// 5. setInput -> renders 'Ann'
fixture.componentRef.setInput('name', 'Ann');

@Component({
  selector: 'app-save',
  template: `<button (click)="save()">{{ saving ? 'Saving…' : 'Save' }}</button>`,
})
class SaveButton {
  saving = false;
  async save() {
    this.saving = true; // runs inside the click handler -> rendered
    await fakeSave();
    this.saving = false; // runs later, in a promise continuation -> NOT rendered
  }
}

OnPush is a component-level opt-out from "check me on every pass". An OnPush component's update pass is skipped unless the component has been marked dirty since its last check. It gets marked when:

• an input receives a new value (compared by reference: !==),
• an event fires from its template (or its host),
• a signal its template read changes,
• markForCheck() is called on it or on a descendant (the async pipe does this),

…and in each case the mark also applies to its ancestors so the walk can reach it.

In Angular 22, OnPush is the default. This is easy to miss and worth saying in an interview, so here is the evidence:

declare enum ChangeDetectionStrategy {
    /**
     * Use the `CheckOnce` strategy, meaning that automatic change detection is deactivated
     * until reactivated by setting the strategy to `Default` (`CheckAlways`).
     * ...
     * NOTE: OnPush is enabled by default.
     */
    OnPush = 0,
    /**
     * Use the `Eager` strategy, meaning that the component is checked eagerly when the change
     * detection traversal reaches it, rather than only checking under certain circumstances (e.g.
     * `markForCheck`, a signal in the template changed, etc).
     */
    Eager = 1,
    /**
     * This value is equivalent to setting `Eager` and is due to be removed.
     * @deprecated Use `Eager` instead.
     */
    Default = 1
}

@Component({
  selector: 'app-host',
  imports: [PlainEager, PlainDefault],
  template: `<span>{{ tick() }}</span><app-plain /><app-plain-default />`,
})
class Host {
  tick = signal(0);
}

const f = TestBed.createComponent(Host);
await f.whenStable();
eager.label = 'changed'; // PlainEager instance
onPush.label = 'changed'; // PlainDefault instance (OnPush)
f.componentInstance.tick.set(1); // something else triggers CD
await f.whenStable();
// <app-plain>         shows 'changed'  (Eager: checked when its parent is refreshed)
// <app-plain-default> shows 'start'    (OnPush: not dirty, skipped)

Rohit's notes single out the "Angular mutation problem" because it's the most common OnPush bug. An OnPush child decides whether its input changed with a reference comparison. If the parent pushes into the same array, the reference is unchanged, so from the child's point of view nothing happened.

@Component({
  selector: 'app-todo-count',
  template: `<p class="child">{{ todos().length }} todos</p>`,
  // OnPush is the default in Angular 22
})
class TodoCount {
  todos = input.required<string[]>();
}

@Component({
  selector: 'app-todo-count-eager',
  template: `<p class="eager">{{ todos().length }} todos</p>`,
  changeDetection: ChangeDetectionStrategy.Eager,
})
class TodoCountEager {
  todos = input.required<string[]>();
}

@Component({
  selector: 'app-todos',
  imports: [TodoCount, TodoCountEager],
  template: `
    <p class="parent">{{ todos.length }} in parent</p>
    <app-todo-count [todos]="todos" />
    <app-todo-count-eager [todos]="todos" />
    <button class="mutate" (click)="addByMutation()">mutate</button>
    <button class="replace" (click)="addByReplacing()">replace</button>
  `,
})
class Todos {
  todos = ['learn signals'];
  addByMutation() {
    this.todos.push('learn OnPush'); // same array reference
  }
  addByReplacing() {
    this.todos = [...this.todos, 'learn immutability']; // new reference
  }
}

// After first render: parent '1 in parent', OnPush '1 todos', Eager '1 todos'
// Click mutate:       parent '2 in parent', OnPush '1 todos', Eager '2 todos'
// Click replace:      parent '3 in parent', OnPush '3 todos', Eager '3 todos'

@Component({
  selector: 'app-todos-signal',
  imports: [TodoCount],
  template: `
    <p class="parent">{{ todos().length }} in parent</p>
    <app-todo-count [todos]="todos()" />
  `,
})
class TodosSignal {
  todos = signal(['learn signals']);
}

// todos().push('oops')                        -> parent '1 in parent', child '1 todos'
// todos.update((t) => [...t, 'fixed'])        -> parent '3 in parent', child '3 todos'

Both live on ChangeDetectorRef (inject it with inject(ChangeDetectorRef)), both are about "this component needs updating", and Rohit's notes flag them as easy to confuse. The difference is when and how much:

• markForCheck() says "this view is dirty — include it next time". It marks the component and every ancestor up to the root (so the top-down walk reaches it) and, zoneless, schedules a tick. It doesn't render anything itself; the render happens on the scheduled pass.
• detectChanges() says "check this view right now, synchronously". It runs the update pass for this component and its children immediately, and doesn't touch ancestors.

@Component({ selector: 'app-cdr', template: `<p>{{ label }}</p>` })
class Cdr {
  cdr = inject(ChangeDetectorRef);
  label = 'start';
}

it('markForCheck schedules; detectChanges is synchronous', async () => {
  const f = TestBed.createComponent(Cdr);
  await f.whenStable();
  const c = f.componentInstance;

  c.label = 'marked';
  c.cdr.markForCheck();
  expect(text(f)).toBe('start'); // nothing yet
  await f.whenStable();
  expect(text(f)).toBe('marked'); // rendered on the scheduled pass

  c.label = 'detected';
  c.cdr.detectChanges();
  expect(text(f)).toBe('detected'); // rendered right now
});

@Component({ selector: 'app-det', template: `<p>{{ label() }}</p>` })
class Det {
  cdr = inject(ChangeDetectorRef);
  label = signal('start');
}

f.componentInstance.cdr.detach();
f.componentInstance.label.set('changed');
await f.whenStable();
// <p> still 'start'
f.componentInstance.cdr.detectChanges();
// <p> now 'changed'

markForCheck() and template events mark a component and all its ancestors dirty, so every OnPush component on the path from the root re-runs its template. Signals do better. When a signal read by a template changes, Angular marks only that template's view for refresh, and marks the ancestors merely as "has a descendant that needs refreshing". The pass walks down past the ancestors without re-running their templates and refreshes only the view that read the signal. That's the right-hand side of the diagram in Zoneless Angular.

This test counts template executions with a method call in each template (the counter increments every time the template's update pass runs):

let parentRenders = 0;
let childRenders = 0;

@Component({
  selector: 'app-child',
  template: `<p>{{ count() }} {{ renders() }}</p>`,
})
class Child {
  cdr = inject(ChangeDetectorRef);
  count = signal(0);
  renders() {
    return ++childRenders;
  }
}

@Component({
  selector: 'app-parent',
  imports: [Child],
  template: `<h1>{{ renders() }}</h1><app-child />`,
})
class Parent {
  renders() {
    return ++parentRenders;
  }
}

// first render:            { parentRenders: 1, childRenders: 1 }
// child.count.set(1):      { parentRenders: 1, childRenders: 2 }
// child.cdr.markForCheck(): { parentRenders: 2, childRenders: 3 }

Some parts of a page are heavy and not needed right away: a chart below the fold, a comments section, an admin-only panel. @defer lets you write them in the template as usual while Angular splits their code into a separate lazy chunk and loads it only when a trigger fires. Lazy routes do this per page (see Lazy loading); @defer does it per block inside a page.

@Component({
  selector: 'app-dashboard',
  imports: [HeavyChart],
  template: `
    <h2>Sales</h2>
    @defer (on viewport; prefetch on idle) {
      <app-heavy-chart [width]="300" />
    } @placeholder (minimum 200ms) {
      <p class="placeholder">Chart will load when you scroll here</p>
    } @loading (after 100ms; minimum 500ms) {
      <p class="loading">Loading chart…</p>
    } @error {
      <p class="error">Could not load the chart</p>
    }
  `,
})
export class Dashboard {}

Initial chunk files | Names         |  Raw size | Estimated transfer size
chunk-Y2L5AXSU.js   | -             | 120.53 kB |                36.16 kB
main-BLTQTV4Y.js    | main          |  89.05 kB |                22.67 kB
styles-5INURTSO.css | styles        |   0 bytes |                 0 bytes

                    | Initial total | 209.58 kB |                58.83 kB

Lazy chunk files    | Names         |  Raw size | Estimated transfer size
chunk-LXYC27NO.js   | heavy-chart   | 549 bytes |               549 bytes

it('shows the placeholder, then the real content', async () => {
  TestBed.configureTestingModule({ deferBlockBehavior: DeferBlockBehavior.Manual });
  const f = TestBed.createComponent(Dashboard);
  await f.whenStable();
  const el = f.nativeElement as HTMLElement;
  expect(el.querySelector('.placeholder')?.textContent).toContain('Chart will load');
  expect(el.querySelector('app-heavy-chart')).toBeNull();

  const [block] = await f.getDeferBlocks();
  await block.render(DeferBlockState.Loading);
  expect(el.querySelector('.loading')?.textContent).toBe('Loading chart…');

  await block.render(DeferBlockState.Complete);
  expect(el.querySelector('app-heavy-chart svg')?.getAttribute('width')).toBe('300');
  expect(el.querySelector('.placeholder')).toBeNull();
});

A client-rendered Angular app sends a nearly empty index.html plus JavaScript; the user sees nothing until that JavaScript downloads and runs. Server-side rendering (SSR) runs the same Angular app on the server for each request and sends real HTML, so the page is visible immediately and search engines and link previews see content. Static site generation (SSG / prerendering) does the same at build time for routes whose content doesn't depend on the request.

The HTML from the server is just HTML — not interactive yet. Hydration is the browser-side step where Angular boots, walks the existing DOM, matches it to its component tree and attaches listeners, reusing the server's DOM nodes instead of destroying and re-creating them (the old pre-hydration behaviour caused a visible flicker).

import { ApplicationConfig } from '@angular/core';
import { provideClientHydration } from '@angular/platform-browser';

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(), // DOM reuse + HTTP transfer cache + incremental hydration (22 defaults)
  ],
};

@defer (hydrate on viewport) {
  <app-heavy-chart />
} @placeholder {
  <p>chart</p>
}

@defer (hydrate on interaction) {
  <app-comments />
}

@defer (hydrate never) {
  <app-static-footer />
}

Most Angular performance work is about doing less: fewer checks, less work per check, less JavaScript up front. In rough order of impact for a typical app: