What Is Hydration

Modern Angular performs non-destructive hydration: it walks the existing DOM, matches it to the component tree, and reuses the nodes. No flicker, less work, better performance.

Reusing server HTML means the largest content stays painted, helping LCP, and avoids layout shifts from re-rendering, helping CLS. The app becomes interactive without redrawing.

Phase one: server renders HTML and sends it. Phase two: the browser downloads JS, boots Angular, and hydrates the existing markup so it becomes interactive.

Hydration assumes the client component tree produces the same structure the server produced. If they diverge, Angular reports a hydration mismatch.

Direct DOM manipulation, browser-only branches that change markup, invalid HTML nesting, and non-deterministic content (like Math.random() or Date.now() in templates) cause mismatches.

Do not manipulate the DOM imperatively (for example with innerHTML outside Angular) during SSR. Let Angular own the DOM so client and server agree.

For a component that genuinely cannot hydrate (such as a third-party widget that mutates the DOM), opt it out with ngSkipHydration; Angular will re-render just that subtree.

Hydration only applies when there is server-rendered HTML to reuse. A pure CSR app has nothing to hydrate; hydration is the client half of the SSR story.

Hydration can be full (whole app hydrates on load) or incremental (parts hydrate on demand). Choosing the right strategy is key to performance, covered in later lessons.

Hydration reuses server HTML on the client non-destructively, improving LCP and CLS. Mismatches arise from manual DOM edits or non-deterministic markup; use ngSkipHydration as an escape hatch. Hydration is the client half of SSR.