What is Server-Side Rendering?
Server-side rendering (SSR) generates a page’s initial HTML on the server and sends it to the browser. Client-side JavaScript may subsequently hydrate that HTML to provide interactive behavior.
How Server-Side Rendering works
SSR executes component rendering on a server for each request or from a server-side cache, producing an HTML representation that can be displayed before the application bundle runs. Hydration then attaches client logic to matching markup when interactivity is needed. This differs from static generation, which creates HTML ahead of requests, and from purely client-rendered pages that begin with a minimal shell. SSR sits in the web delivery path and can combine request context, backend data, and routing before response.
Key facts
- Hydration expects the client’s initial tree to match the server markup; locale, time, randomness, or browser-only branches can cause mismatches and discarded work.
- Server rendering can improve first-content availability, but slow backend data or uncached computation increases time to first byte unless work is streamed or cached.
- Code executed during SSR has no browser DOM, and components marked for the client can still render on the server for the initial HTML, so read window or document only in browser-only code such as effects or event handlers, and load modules that touch them at import time through a client-side dynamic import.
When Server-Side Rendering matters
Use SSR when initial content, link previews, search discovery, or resilience without JavaScript matters. It adds server rendering work and can cause hydration errors if browser output differs from the server HTML.