SSR Hydration: Don't Re-render, Reuse
Hydration tells your client-side app to reuse the HTML sent by the server instead of wastefully re-rendering it. This prevents UI flicker in Server-Side Rendered apps and improves load performance.
Why it exists
Server-Side Rendering (SSR) sends a fully rendered HTML page for a fast initial paint. But when the client-side JavaScript loads, it traditionally destroys that HTML and re-renders the entire application from scratch. This is wasteful and causes a jarring UI flicker, negating some of SSR's performance benefits.
The mental model
Hydration is the process of "inflating" static, server-rendered HTML with client-side interactivity. Instead of bulldozing the server's work and rebuilding, the client-side framework walks the existing DOM, matches it to its component structure, and attaches event listeners and state. It's like receiving a pre-assembled model car and just needing to add the batteries to make it run.
How it works
When an Angular app with hydration enabled bootstraps in the browser, it doesn't create new DOM nodes. Instead, it scans the existing HTML received from the server. It identifies which DOM elements correspond to which components in its internal tree. Once matched, it reuses those DOM nodes, attaches event listeners, and restores application state, making the static page fully interactive. In Angular, this is enabled by adding provideClientHydration() to your application providers on both the server and the client.
When to use it
Use hydration in any Server-Side Rendered (SSR) Angular application. It's the key to unlocking the full performance benefits of SSR by improving Core Web Vitals like Largest Contentful Paint (LCP) and First Input Delay (FID), which also benefits SEO. Without it, you get a fast first paint followed by a slow, disruptive re-render.
When not to use it
Don't enable hydration if your application is purely client-side rendered (CSR), as there's no server-rendered DOM to hydrate. More importantly, you must disable hydration for specific components (using ngSkipHydration) that perform direct DOM manipulation, like using document.getElementById or integrating a non-Angular library that writes to the DOM. Hydration fails if Angular doesn't have exclusive control of the DOM structure.
One canonical example
You enable SSR in your Angular app using ng add @angular/ssr. The CLI automatically adds provideClientHydration() to your app's providers. When you run the app and view the browser console in dev mode, you'll see a message like "Angular hydrated 50 components and 200 nodes," confirming that the client app successfully reused the server's DOM instead of rebuilding it.
Interview question
In a Server-Side Rendered (SSR) application, what is the primary goal of hydration?
- a.To reduce the initial HTML payload size by deferring all content rendering to the client-side JavaScript.
- b.To enable direct manipulation of the DOM by third-party libraries without interfering with Angular's component structure.
- c.To completely rebuild the DOM on the client-side to ensure all interactive elements function correctly.
- d.To attach event listeners and restore application state to existing server-rendered HTML, preventing UI flicker.Correct
Why? this is the answer
Hydration's main purpose is to reuse the server-rendered HTML by attaching event listeners and restoring state, making it interactive without re-rendering. Option C describes the problem hydration solves, not its solution, as it explicitly avoids rebuilding the DOM.
Just read this? Test yourself on what you have been reading.
Read the original → angular.dev
- #angular
- #ssr
- #hydration
- #performance
- #frontend
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on angular — each one lists the topics its interview covers.
See open roles