Week 20: Performance Optimization & Zoneless Change Detection

1. Zoneless Change Detection & OnPush

Back in Week 3, you learned that Zone.js patches async browser APIs so Angular knows "something happened, time to check for changes" — then re-checks the entire component tree by default. OnPush narrows that: a component only re-checks when one of its @Input()s changes by reference, an event originates inside it, or an async-piped Observable emits.

import { Component, ChangeDetectionStrategy } from '@angular/core';

@Component({
  selector: 'app-product-card',
  templateUrl: './product-card.html',
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class ProductCard {}

Signals make OnPush essentially free to adopt everywhere: a signal read in a template automatically and precisely marks that component for a check when the signal changes — you get OnPush's performance benefit without OnPush's classic downside (accidentally mutating an object in place and wondering why the view didn't update).

import { provideZonelessChangeDetection } from '@angular/core';

export const appConfig: ApplicationConfig = {
  providers: [
    provideZonelessChangeDetection(), // no Zone.js at all
  ],
};

Zoneless removes Zone.js from the bundle and its runtime patching overhead entirely — Angular now relies purely on explicit signals of "something might have changed" (a signal write, a manually called markForCheck()) instead of monkey-patching every async API in the browser to guess. An app built signal-first, with OnPush everywhere, is already most of the way there — zoneless just removes the safety net you no longer need.

2. Profiling with Angular DevTools & the Chrome Performance Panel

You installed Angular DevTools back in Week 2 — its Profiler tab records a timeline of every change-detection cycle, showing exactly which components were checked and how long each took. This is where you find "this component re-renders far more than it should."

// In Angular DevTools -> Profiler tab:
// 1. Click "Record", interact with your app, click "Stop"
// 2. Each bar in the timeline is one change-detection cycle
// 3. Click a bar to see every component checked during it, and how long each took
// 4. A component checked on EVERY cycle, with no visible reason, is your first suspect

Chrome's own Performance panel operates one level lower — a full flame chart of everything the main thread did, including script execution, layout, and paint. Reach for it when the problem isn't "which component re-rendered" but "why did the browser freeze for 200ms" — a long, uninterrupted JavaScript task is exactly what a flame chart makes visually obvious.

3. Bundle Analysis & Lazy-Loading Strategy Review

You set up lazy loading back in Week 11 — bundle analysis is how you verify it's actually working, and catch a dependency that snuck into the initial bundle by accident.

ng build --stats-json
npx esbuild-visualizer --metadata dist/my-app/stats.json --filename bundle-report.html

The resulting treemap shows exactly what's in each chunk, sized proportionally to actual bytes — a huge, unexpected block in your initial bundle (rather than a lazy chunk) is the classic sign of an accidentally-eager import, like a heavy charting library imported at the top of a shared file instead of only inside the lazy-loaded route that actually uses it.

4. Image Optimization with NgOptimizedImage

Images are frequently the single biggest contributor to a slow page load. NgOptimizedImage is a directive enforcing best practices you'd otherwise have to remember by hand every time.

<img
  [ngSrc]="product.imageUrl"
  width="400"
  height="300"
  [priority]="isAboveTheFold"
  alt="{{ product.name }}"
/>

• ngSrc instead of src — enables automatic srcset generation and lazy loading by default.
• width/height are required — without them, the browser can't reserve space before the image loads, causing layout shift as content jumps once it arrives.
• priority disables lazy loading for exactly one image — the largest visible one on initial load (the Largest Contentful Paint candidate), which should load immediately rather than being deferred.

Skipping priority on your actual LCP image is a common mistake — lazy loading is right for most images, but the one thing users see first shouldn't be deferred at all.

5. Virtual Scrolling with the CDK

Rendering a list of thousands of items — even simple ones — means thousands of live DOM nodes, which is slow to create and slow for the browser to manage. Virtual scrolling renders only the handful of rows currently visible in the viewport, recycling DOM nodes as the user scrolls.

<cdk-virtual-scroll-viewport itemSize="56" class="viewport">
  <div *cdkVirtualFor="let item of items()" class="row">
    {{ item.name }}
  </div>
</cdk-virtual-scroll-viewport>

.viewport {
  height: 500px; /* the viewport needs an explicit, bounded height to know how much to render */
}

itemSize tells the viewport the fixed height of each row up front, so it can calculate scroll position and total scrollable height without ever needing to measure every single item. For a list of 10,000 rows, this is the difference between 10,000 live DOM nodes and roughly a dozen.

6. Memory Leak Detection & Fixes

You already know the most common source of a memory leak — an unmanaged subscription from Week 15. Chrome's Memory panel is how you actually confirm one exists rather than suspecting it.

// In Chrome DevTools -> Memory panel:
// 1. Take a heap snapshot (baseline)
// 2. Navigate to a component, then navigate AWAY from it (it should be destroyed)
// 3. Repeat step 2 several times
// 4. Take a second heap snapshot, filter by the component's class name
// 5. If instances of a supposedly-destroyed component are still present -> it's leaking

A component instance surviving navigation almost always means something is still holding a reference to it — most commonly an unmanaged subscription (fixed with takeUntilDestroyed(), Week 15) or an event listener registered on a long-lived global object (like document or window) that was never removed in ngOnDestroy.

export class ResizeAwarePanel implements OnDestroy {
  private handleResize = () => this.recalculate();

  constructor() {
    window.addEventListener('resize', this.handleResize); // window outlives every component
  }

  ngOnDestroy() {
    window.removeEventListener('resize', this.handleResize); // without this line: a leak
  }
}

7. Hands-on Exercise

8. Knowledge Check

Four quick questions. Expand each to check your answer.