SSR returns HTML from the server, so users see content before the JS bundle even loads. The benefits are real and significant — but so are the trade-offs.

Benefits

1. Fast first paint

CSR: HTML arrives nearly empty → user waits for JS bundle download + parse + execute + data fetch + render to see anything.

SSR: HTML arrives with content → user sees text/images immediately (FCP / LCP improve dramatically, especially on slow networks or low-end devices).

2. SEO

Crawlers may execute JS but rank pages with content in the initial HTML higher — especially for content not behind interactions. SSR makes the content present in the HTML response.

3. Link previews / Open Graph

Social link previews (Slack, Twitter, Facebook) fetch the URL and parse the HTML. They generally don't run JS. SSR ensures <title>, <meta>, and Open Graph tags are populated.

4. Performance on low-end devices

Low-end phones spend seconds parsing/executing big JS bundles. Server-rendered HTML lets them paint immediately and progressively become interactive.

5. Streaming + Suspense

React 18 streaming SSR lets you flush HTML progressively — the shell renders first, slow data widgets render later — best of both worlds.

6. Smaller perceived latency

Even with the same total time, users perceive faster apps when something visible happens early. SSR's first paint is much earlier than CSR's.

Trade-offs

Origin cost per request

The server renders React for every request (unless cached). CPU, memory, and concurrency cost. Edge caching (CDN/ISR) mitigates.

TTFB depends on server

If the server takes 1.5s to render, FCP can't be under 1.5s. CSR's TTFB is fast even if render is slow.

Hydration cost

After SSR HTML arrives, React must run the same component tree on the client to attach event handlers — hydration. This is a long task; on big apps it can hurt INP and even cause the page to "look ready but be uninteractive."

Mismatches

If server and client render differently (e.g., a date based on local time, or randomly generated id), hydration mismatches occur — React warns and may discard server HTML. See [[what-is-hydration-in-nextjs-and-when-can-it-cause-ui-mismatches]].

Server complexity

Now you have a server. Auth, sessions, caching, scaling — all server concerns you didn't have with CSR.

When to choose SSR

Alternatives — SSG, ISR, RSC, Streaming

• SSG — pre-render at build, serve from CDN. Fastest globally. Use when content rarely changes.
• ISR — SSG + revalidation. Most of SSG's speed with periodic refresh.
• Streaming SSR — Suspense + flushed chunks. Fast FCP without blocking on slow data.
• React Server Components — render on server, ship zero JS for non-interactive parts. Reduces hydration cost.

Modern Next.js apps hybridize all of these per route.

The hydration reality

The "looks ready but isn't interactive" problem is real. Modern fixes:

• Code-split so hydration isn't one huge task.
• React Server Components — interactivity only where needed.
• Progressive hydration / island architecture (Astro) — hydrate only what's interactive.

Interview framing

"SSR ships HTML with content in it, so the user sees text/images before the JS bundle loads — better FCP/LCP, better SEO, better link previews, much better perceived perf on slow networks and low-end devices. The trade-offs are real: origin cost per request, TTFB tied to server render time, and hydration is a long task that can hurt INP — the page can look ready before it actually is. Modern mitigations: edge caching / ISR for origin cost, streaming + Suspense so slow data doesn't block first paint, and React Server Components to skip hydration entirely for non-interactive parts. The rule: SSR for SEO/content-heavy pages, CSR for app-shell post-login surfaces, and hybridize per route — modern Next.js makes that easy."