How it works
When a request arrives, the server fetches the data, renders the components to HTML and sends a complete page. The browser can show it immediately; then the JavaScript loads and hydrates the page to make buttons and forms work. Because the page is built per request, it can be personalised, for example to show the signed-in user's basket.
This is how PHP, Rails and Django sites have always worked, and frameworks such as Next.js, Nuxt, SvelteKit and React Router bring it to component-based apps. Streaming lets the server send the page in pieces, so slow parts do not hold up the rest. The trade-off is a server doing work on every request, which costs money and adds delay when it sits far from the visitor or the data.
Server-side rendering (SSR) pros and cons
Pros
- Content is visible quickly, even before JavaScript runs
- Search engines and link previews see the full page
- Fresh, personalised data on every request
- Secrets and heavy logic stay on the server
Cons
- A server works on every request, which costs money
- Slower than static pages when the server or data is far away
- Hydration still ships JavaScript for interactivity
- More moving parts: caching, timeouts and server errors
When to use Server-side rendering (SSR)
Pick it when
- Pages that change per visitor or per request, such as search results
- Stores and listings that need both SEO and fresh stock or prices
- Signed-in pages that must also load quickly
Skip it when
- Pages that are the same for everyone and rarely change (use SSG)
- Very high traffic, where serving cached static pages is far cheaper
Server-side rendering (SSR) vs the alternatives
Related terms
More in Rendering and architecture
Where pages are built