Why serve an Angular page from the server if the app is interactive?
Explain first content, hydration, and which work must not run twice.
Points worth saying
- Server HTML gives crawlers and first paint the real text.
- Hydration attaches events to that HTML instead of redrawing it.
- Browser-only APIs belong behind a check, after the document exists.
A full answer
A client-only render sends an empty shell. The title, question text, and links appear after JavaScript runs. A crawler that does not execute JavaScript, and a visitor on a slow device, see that shell first.
Server rendering runs the same components on the server and sends HTML with the content in place. The browser then hydrates: it reuses the DOM and attaches listeners. Event replay covers interactions that happened before hydration finished.
The failure mode is code that assumes a browser during construction: window, localStorage, or a random id that will not match on the client. Those belong in afterNextRender or a platform check. If server and client markup differ, hydration fails and the page can flicker.
Use the server for public pages that should be indexed: topics, questions, pricing, and the landing page. Keep private progress on the client if it depends on storage that the server cannot see, and mark those URLs noindex.
Mark your progress
Create a practice profile to mark this question.