Hydration and Incremental Hydration in Angular

Hydration in SSR applications is described as activating server-rendered HTML on the client by attaching event listeners, restoring state, and reusing DOM nodes. The article says this avoids redundant rendering and helps metrics such as FID, LCP, and CLS. It also lists limits of full-application hydration, including downloading all JavaScript at once, the “uncanny valley” before interactivity arrives, and layout shifts from placeholders.

Reading notes

#

• Hydration activates server-rendered HTML on the client by attaching event listeners, restoring state, and reusing DOM nodes.
• The article links hydration to better FID, LCP, and CLS because it avoids rerendering content the server already produced.
• Traditional full hydration can slow initial loads, create a gap between appearance and interactivity, and cause layout shifts.
• Angular’s path to incremental hydration is described through full hydration in Angular 16, deferrable views in Angular 17, and EventReplay in Angular 18.
• Angular 19 adds incremental hydration so parts of an app can hydrate on demand instead of all at once.
• The triggers named in the article are viewport entry, user interaction, idle time, and timers.
• To use it, the application must already use SSR and hydration, then add withIncrementalHydration() in bootstrap configuration.
• The @defer directive can pair with hydration triggers in templates, such as hydrating a shopping cart when it enters the viewport.
• The article also shows hydration on interaction with a placeholder, and hydrate never for static content such as a footer.
• Angular 19 combines dehydrated server-rendered content, event replay, and selective activation to reduce unnecessary JavaScript downloads and improve user experience.