Hydration

Modern Angular SSR hydrates the existing DOM in place instead of throwing it away — no flicker, faster TTI, fewer flashes of unstyled content.

4 min read Level 3/5 #angular#ssr#hydration

What you'll learn

Enable hydration with provideClientHydration
See faster Time-To-Interactive and no FOUC
Diagnose hydration mismatches

Without hydration, the client-side Angular boot wipes the server-rendered DOM and redraws everything. That works, but it costs a visible flicker and forces the browser to re-parse markup it already had. Hydration is the fix.

Turn It On

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

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(),
    // ...other providers
  ],
};

That’s it. The next time the app boots in the browser, Angular walks the SSR’d DOM, attaches event listeners, and keeps the existing nodes in place.

What You Get

No flicker — pixels never change between server HTML and hydrated app.
Faster TTI — the browser doesn’t redo layout for content it already rendered.
Lower CPU at startup — fewer DOM operations on a cold load.

Hydration Mismatches

If the server HTML and the client’s first render disagree, hydration logs a warning and falls back to re-rendering. Common causes:

// Bad: differs every render
greeting = computed(() => `Hello at ${new Date().toLocaleTimeString()}`);

// Bad: random in the constructor — server vs client values disagree
id = Math.random();

// Bad: branching on window directly inside the template

Move time-based or random values behind afterNextRender, or skip them on the server using isPlatformBrowser. Open DevTools and watch for NG0500 warnings — they tell you exactly which node didn’t match.

Performance →