CSR vs SSR vs SSG vs ISR: Web Rendering Strategies

Web rendering strategies compared: client-side rendering, server-side rendering, static generation, ISR, hydration and streaming, and when to use each.

Intermediate 3 min read · Updated

A rendering strategy decides where and when a web page's HTML is produced. Client-side rendering (CSR) sends a mostly empty page and builds it in the browser with JavaScript. Server-side rendering (SSR) builds HTML on the server for every request. Static site generation (SSG) builds HTML once at deploy time. Incremental static regeneration (ISR) rebuilds static pages in the background after they go stale. Each trades first-load speed, freshness, server cost and complexity differently.

The four strategies compared

CSRSSRSSGISR
HTML producedIn the browserOn the server, per requestAt build timeAt build time, then refreshed in the background
First contentful paintSlow: wait for JS to download and runFastFastest (served from a CDN)Fastest
Data freshnessLiveLiveAs of the last buildWithin the revalidation window
Server costLow (static files plus APIs)Highest: render every requestLowestLow
SEOWeaker: crawlers must run JSStrongStrongStrong
Personalised pagesEasyEasyNo (same HTML for everyone)No, unless combined with client fetching
Good forDashboards and apps behind loginPersonalised or fast-changing public pagesDocs, blogs, marketing, handbooksLarge catalogues that change occasionally

Hydration and its cost

With SSR and SSG, the browser receives complete HTML and paints it quickly. To make it interactive, the framework downloads the JavaScript and hydrates: it re-runs the components and attaches event handlers to the existing HTML. Until hydration finishes, buttons may not respond, which shows up in Interaction to Next Paint (INP). Large pages with heavy JavaScript can look ready but feel broken for a few seconds on slow phones. See Core Web Vitals.

  • Partial or islands hydration: only hydrate interactive parts (a search box, a carousel), leaving static content as plain HTML.
  • Streaming SSR: send HTML in chunks as data becomes ready, so the top of the page paints before slow sections finish.
  • Server components: render some components only on the server and send their output, shipping less JavaScript to the client.
  • Progressive enhancement: make core content and links work without JavaScript, then enhance.

Choosing a strategy

yesnoyesnoMust search engines index it?CSRapp behind loginSame for every visitor?SSG / ISRCDN-servedSSR (streaming)per request
A quick decision path: public content that changes rarely is static; public content that's personalised or live is server-rendered; private app screens can render on the client.

Most real sites mix strategies per route: a statically generated marketing site and handbook, server-rendered product pages, and a client-rendered app behind login. A common hybrid is a static or server-rendered shell with personalised parts fetched on the client.

This handbook is an example: every page is prerendered to static HTML at build time for fast loads and indexing, then the app hydrates for interactive features like search and progress tracking.

Caching each strategy

  • SSG output is immutable per deploy and cached at the CDN edge. See CDN.
  • SSR responses can be cached briefly at the edge for anonymous users (s-maxage with stale-while-revalidate), but never shared when personalised.
  • ISR is essentially edge caching with background regeneration on a timer or an explicit revalidation call when content changes.
  • CSR apps cache their JavaScript bundles with content-hashed filenames and long lifetimes. See browser caching.

Where it’s used

E-commerce

SSG or ISR for category and product pages at scale, with prices and stock fetched on the client or via SSR.

News sites

SSR or short-lived ISR keeps articles fresh and indexable within seconds of publishing.

SaaS dashboards

CSR behind login, since SEO doesn't matter and data is per user.

In an interview

  • Compare CSR, SSR, SSG and ISR on first paint, freshness, cost and SEO.
  • Explain hydration and its effect on interactivity.
  • Choose per route rather than for the whole site.
  • Describe how each strategy is cached at the CDN and in the browser.

Further reading