What is server-side rendering in React?
By FrontendPro Editorial Team Updated 9/26/2026
Answer
Server-side rendering means the server runs your React components on each request and sends back finished HTML. The browser paints that HTML immediately, then downloads the JavaScript and hydrates it into a live app.
// the server produces markup, not an empty <div id="root">
const html = await renderToReadableStream(<App url={req.url} />);
Compare the three pipelines:
| first response | data freshness | work per request | |
|---|---|---|---|
| Client rendering | empty shell | fetched in browser | none |
| SSR | full HTML | per request | render + data |
| Static generation | full HTML | as of build | none |
What you get
- Faster first paint. Content appears without waiting for the bundle to download, parse, and run. On a slow phone that is the difference between 1s and 4s.
- SEO and link previews. Crawlers and social scrapers see real content. Google does execute JavaScript, but not reliably or promptly, and most other crawlers do not at all.
- Per-request data. Unlike static generation you can render a personalised dashboard or a page that depends on cookies and headers.
- Less work in the browser, which matters most on the devices that are already struggling.
What it costs
- A server, and time on it. Every request costs CPU and a data fetch, so you need caching and you need to think about load.
- TTFB goes up. The user waits for the server to finish before anything arrives — unless you stream, which is why React has
<Suspense>boundaries flushing HTML in chunks. - Two environments. No
windowordocumentduring render, so browser-only code must move into an effect or a client-only component. Any value that differs between the two —Date.now(),Math.random(), locale formatting — produces a hydration mismatch. - Hydration is not free. The HTML is visible but not yet interactive; a click before hydration completes does nothing. This is the gap TTI measures.
How it looks in practice
In the Next.js App Router, Server Components are the default and run only on the server; "use client" marks the parts that also ship to the browser. SSR then happens per request unless the route is statically generated or revalidated, so the real decision you make per page is: static, revalidated on an interval, or dynamic.
When not to use it
An app behind a login with no SEO need and no first-paint pressure — an internal dashboard, an editor — gains little from SSR and pays the whole complexity bill.