SSR vs. CSR vs. SSG: how web rendering works

SSR vs. CSR vs. SSG is a comparison of rendering strategies by where and when HTML is generated: build time, server, or browser. That single axis — where and when — determines SEO, performance, data freshness, and cost; everything else is downstream of it. And the backend-developer’s clarification the frontend guides bury: rendering is a frontend concern; the data is a backend one. All three strategies call the same API; they differ only in the moment they call it.

Key takeaways

Same data, three call times

// JavaScript — the SAME API call, consumed three ways.
// Rendering is a FRONTEND choice; the data is a BACKEND concern.
async function getPosts() {
  const q = new Parse.Query('Post').equalTo('published', true).limit(20);
  return q.find(); // one backend endpoint — the ONLY thing that changes is WHEN
}

// SSG — called at BUILD time; data baked into static HTML, served from a CDN.
// SSR — called PER REQUEST on the server; fresh HTML sent to the browser.
// CSR — called FROM THE BROWSER after load; the client builds the DOM.
// You don't change the backend to switch rendering — only when/where you fetch.

// Flutter / Dart — Back4app Flutter SDK
// Whatever the rendering strategy, the data comes from one backend API.
Future<List<ParseObject>> getPosts() async {
  final q = QueryBuilder<ParseObject>(ParseObject('Post'))
    ..whereEqualTo('published', true)
    ..setLimit(20);
  return (await q.query()).results?.cast<ParseObject>() ?? [];
}
// SSG fetches at build, SSR fetches per request, CSR fetches in the client —
// the endpoint is identical; only the timing and location differ.

// Swift — Back4app Swift SDK
// Whatever the rendering strategy, the data comes from one backend API.
func getPosts() async throws -> [Post] {
    try await Post.query("published" == true).limit(20).find()
}
// SSG fetches at build, SSR fetches per request, CSR fetches in the client —
// the endpoint is identical; only the timing and location differ.

// Kotlin — Back4app Android SDK
// Whatever the rendering strategy, the data comes from one backend API.
fun getPosts(): List<ParseObject> {
    val q = ParseQuery.getQuery<ParseObject>("Post")
    q.whereEqualTo("published", true)
    q.limit = 20
    return q.find()
}
// SSG fetches at build, SSR fetches per request, CSR fetches in the client —
// the endpoint is identical; only the timing and location differ.

One getPosts(), one backend endpoint. SSG calls it at build time and bakes the result into static HTML; SSR calls it per request on the server and sends fresh HTML; CSR calls it from the browser after load. You never change the backend to change rendering — only the moment and the place you fetch. That’s the fact that turns a confusing three-way comparison into one decision.

SSR vs. CSR vs. SSG, side by side

The metrics, honestly

The trade-offs no comparison states cleanly. SSG wins time-to-first-byte outright and consistently — a CDN hands back a prebuilt file. SSR raises TTFB (the server must render before it can respond) but still beats CSR on first paint, and it ships fresh data. CSR has a fast TTFB (the shell is tiny) but a slow first paint and slow time-to-interactive, because nothing is visible until the bundle runs. And the one everyone glosses: SSR and SSG don’t fix TTI. Both send HTML that looks ready, then hydration — downloading, parsing, and executing the JavaScript to attach interactivity — runs anyway. That’s the “looks ready but isn’t clickable” gap, and it’s why the shipped-JS bill is the real interactivity tax, motivating islands, partial hydration, and server components that ship less of it.

The 2026 spectrum: ISR, streaming, RSC

The trio is a teaching simplification; production is a spectrum. ISR (incremental static regeneration) serves static pages but regenerates them on an interval or on demand — SSG speed with periodic freshness, at the price of occasional staleness. Streaming SSR sends HTML in chunks as it’s generated, so the shell paints in tens of milliseconds while slow content streams behind it. Server components run only on the server, ship zero JavaScript for non-interactive parts, and can read data directly — the newest answer to hydration cost. None of these change the backend contract; they’re finer control over when the HTML forms and how much JS follows it, which is the same axis this whole entry turns on.

It’s per-route, not per-app

The mental upgrade that dissolves most “which one?” debates: you don’t pick one strategy for the whole site. A single app routinely mixes them — a statically generated marketing homepage, an ISR-regenerated product catalog, a server-rendered personalized dashboard, and client-rendered interactive widgets — each route choosing by its own needs. The question is never “SSR or CSR or SSG for my app?” but “which for this page?”, and the answer follows the page’s data: same-for-everyone and stable → static; personalized or fresh → server; behind a login and highly interactive → client.

Which strategy per page? A decision matrix

Common use cases

• Content sites — SSG plus a CDN for instant, crawler-friendly pages (the JAMstack pattern).
• E-commerce — ISR catalog pages, SSR cart and checkout, CSR interactive filters — three strategies, one store.
• SaaS dashboards — CSR behind a login, where SEO doesn’t matter and interactivity does.
• News and publishing — SSR or ISR for freshness with SEO.
• PWAs — a rendered shell plus client-side interactivity and offline caching.

Limitations and trade-offs

• CSR’s SEO risk is real but overstated. Crawlers render JavaScript with a budget; CSR is fine off the indexable path and a gamble on it — nuance, not absolutism.
• SSR costs server compute. Rendering every request has a price in TTFB and infrastructure that a CDN-served static file doesn’t.
• SSG’s freshness lag. Build-time data is stale until the next build; large or fast-changing sites need ISR or long builds.
• Hydration is the hidden tax. Server-rendered HTML still ships JS to become interactive; first paint fast, first click not necessarily.
• Mixing adds cognitive load. Per-route rendering is powerful and means reasoning about several data-fetch timings in one app — the flexibility has a complexity cost.

Rendering on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. It is the constant beneath the rendering choice: the REST and GraphQL APIs feed SSG at build time, SSR per request on the server, and CSR from the browser — the identical endpoint the code tabs show, consumed at three different moments — so switching a route’s strategy never touches the backend. The reframe this article opens with becomes a working convenience: because rendering is a frontend decision and the data lives behind one stable API with its own auth and permissions, a team can prebuild the blog, server-render the dashboard, and client-render the app shell against the same Back4app backend — picking per page, changing nothing underneath.