How does Angular handle server-side rendering (SSR) with Hydration?

Angular Universal's SSR renders the app on the server, sending HTML to the browser. Angular 16 introduced non-destructive hydration — a major improvement over the previous approach. Old approach (without hydration): server sends pre-rendered HTML → browser displays it immediately → Angular bootstraps and completely DESTROYS the server-rendered DOM and recreates it from scratch using client-side JavaScript. This caused flicker, lost scroll position, and wasted the SSR effort for initial content. Non-destructive hydration (Angular 16+): server sends pre-rendered HTML + serialized state (TransferState) → browser displays HTML immediately → Angular bootstraps and REUSES the existing DOM (doesn't recreate) → attaches event handlers to existing DOM nodes → app becomes interactive. The DOM is preserved — no flicker. Enable: bootstrapApplication(AppComponent, { providers: [provideClientHydration()] }). TransferState: transfer server-computed data (HTTP responses, computed values) to the client to avoid duplicate HTTP requests. Server caches responses in TransferState; client reads the cache before making HTTP calls. HttpClient automatically uses TransferState when TransferState is available. Incremental hydration (Angular 17+, experimental): defer hydration of specific parts of the page until they're needed (e.g., components in @defer blocks). Reduces JS execution on initial load. Challenges with SSR: guard server-specific code (no window/document/localStorage on server); handle authentication (cookies vs tokens); third-party libraries may not be SSR-compatible. Performance impact: SSR with hydration dramatically improves Core Web Vitals (LCP, FID, CLS).