Two ways to render a web page. The choice determines first-paint speed, SEO, server cost, and complexity.

SSR — Server-Side Rendering

Server runs the app, generates HTML, sends it to the browser. Browser displays content immediately; React/Vue hydrates to attach event handlers.

Browser request → Server runs app → HTML with content → Browser paints → JS hydrates

Timeline (typical):

• TTFB: server response time (50–500ms).
• FCP/LCP: as soon as HTML arrives + critical CSS applied (1–2s).
• Interactive: after JS bundle loads + hydrates (2–4s).

Pros:

• Fast first paint — user sees real content immediately.
• SEO works out of the box (crawlers see content).
• Social previews work (OG tags in initial HTML).
• Lower JS execution burden on low-end clients.

Cons:

• Server cost per request (no CDN cache by default).
• Slower TTFB than SSG (server has to render).
• Hydration mismatch bugs if server + client see different state.
• Stateful — needs framework support (Next.js, Remix, Nuxt, SvelteKit).

CSR — Client-Side Rendering

Server ships a tiny HTML shell (<div id="root"></div>) + JS bundle. Browser downloads, parses, executes, and renders the app.

Browser request → Empty HTML + JS → Download/parse JS → Render → Fetch data → Re-render

Timeline (typical):

• TTFB: trivial (static shell, often <100ms from CDN).
• FCP: after JS bundle loads + parses (2–4s on mid-range mobile).
• LCP: after data fetches + renders (3–6s).
• Interactive: similar to LCP.

Pros:

• Server is dumb (static shell + JSON API) → cheap, scales horizontally.
• Easy to deploy (drop files on CDN).
• Snappy in-app navigation after initial load (no full reload).

Cons:

• Slow first paint (blank screen until JS loads + executes).
• Bad SEO for non-Google crawlers (they don't run JS).
• Social previews broken (OG tags injected by JS aren't seen).
• Heavy on the client (parse + execute large bundles).

SSG and ISR — SSR's better-cached cousins

SSG: Pre-render at build time. Result is static HTML on a CDN. Best of both worlds for content that doesn't change per-request.

ISR (Incremental Static Regeneration): SSG + on-demand regeneration. Stale-while-revalidate semantics.

Both have SSR's first-paint + SEO benefits but TTFB ≈ CDN edge latency (~50ms globally).

Choosing per page

Modern frameworks (Next.js App Router, Remix, SvelteKit) let you pick per route:

Hydration — the bridge

SSR + React = HTML arrives ready, then React "hydrates" by attaching listeners and reconciling state. Hydration mismatch = SSR produced different HTML than client would have → React warns and re-renders (visible jank).

Common causes:

• Date.now() / Math.random() in render.
• Reading window / localStorage during SSR (won't exist on server).
• Different user agent / locale assumptions.

React Server Components (RSC) + streaming + selective hydration in Next.js 13+ change this further: only interactive components hydrate; the rest stays server-rendered HTML with zero JS.

Performance comparison

For a typical content page on mid-range mobile, 4G:

SSG wins on TTFB + LCP. SSR is close on LCP. CSR is consistently the worst.

Hybrid: the modern pattern

Real apps mix modes:

• Marketing pages: SSG.
• App routes: SSR (server-renders the shell, client hydrates).
• Within the app: client-side navigation between routes (CSR feel).
• Data fetching: React Query / SWR on the client.

Next.js App Router formalizes this: Server Components render on the server (no JS shipped), Client Components hydrate.

Mental model

SSR/SSG/ISR = render now, optimize first paint and SEO. CSR = render on the client, optimize for snappy in-app navigation after the first load. Most apps benefit from rendering on the server first and behaving like a CSR app after.