Static vs SSR vs CSR

Rendering strategy affects performance, resilience, and complexity — choose approaches intentionally, not by trend.

01 — Purpose

Choose rendering on purpose

Rendering strategy affects performance, resilience, and complexity — choose approaches intentionally, not by trend.

Static generation, server-side rendering, and client-side rendering each trade off speed, dynamism, and operational cost. The wrong default — CSR for a marketing site, static for a live dashboard — hurts users and teams alike.

See hydration costs and islands architecture for how interactivity fits after HTML delivery.

02 — Principles

Architecture should match user needs

Not every page needs the same rendering model.

  • Static — pre-built HTML at build time; fast delivery, high resilience, ideal for content-heavy sites
  • SSR — HTML per request; dynamic and personalised content, SEO-sensitive pages
  • CSR — render in the browser; highly interactive apps and client-heavy workflows

03 — Practice

When to use each approach

Mix models per route — not one global choice for the whole product.

  • static for docs, marketing, and standards — like this site; CDN-friendly, minimal TTFB
  • SSR for personalised or frequently changing pages — account home, search results
  • CSR sparingly for dense app shells — dashboards where client state dominates
  • combine static + islands — static HTML with hydrated widgets; see islands architecture
  • measure TTFB and LCP per strategy — see TTFB and backend impact

04 — Avoid

Rendering mismatches

Using CSR unnecessarily for simple content sites is a common and expensive mistake.

  • CSR for content sites — blank shell until JS loads, poor SEO and LCP
  • SSR everything — unnecessary server cost for truly static pages
  • static for highly personalised real-time data — stale or build-heavy workarounds
  • choosing by framework default — not by route requirements
  • ignoring resilience — CSR fails hard when JS errors or networks stall

05 — Close

Match the model to the page

Trends change; user needs and content shape do not.

List your top routes. For each, ask: how often does content change, does it vary per user, and how much client interactivity is required? Pick static, SSR, or CSR — or static plus islands — accordingly.

See progressive hydration, performance budgets, and performance standard.