Skip to content

Rendering Strategies (SSR, SSG, ISR, CSR)

Rendering strategies decide where and when your HTML is built: at build time (SSG), per request on the server (SSR), regenerated on a schedule (ISR), or in the browser (CSR). Each trades freshness, speed, and cost differently.

also: SSR · SSG · ISR · CSR · server-side rendering · static site generation · incremental static regeneration

pick per routeSSG · ISR · SSR · CSRfreshness vs speed vs cost

SSG (static site generation) builds pages once at deploy and serves plain files: fastest and cheapest, but stale until you rebuild, so it suits content that rarely changes. SSR (server-side rendering) builds the HTML on every request: always fresh and good for SEO and personalisation, but it costs server time per view and raises TTFB. CSR (client-side rendering) ships a near-empty shell and renders in the browser: cheap to host but bad for SEO and slow to first paint.

ISR (incremental static regeneration, a Next.js feature) is the middle path: serve a static page, but rebuild it in the background after a set time or on demand, so most users get static speed while the content stays reasonably fresh without a full redeploy. The right choice is per route, not per app. A marketing page wants SSG, a logged-in dashboard wants SSR or CSR, a product catalogue often wants ISR.

free_toolRendering Strategy PickerAnswer four questions and get the right SSG, ISR, SSR, or CSR call with a snippet.

faq

Questions & answers

What is the difference between SSR and SSG?
SSG builds the HTML once at deploy and serves the same file to everyone: fast and cheap but stale until the next build. SSR builds the HTML fresh on each request: always current and able to personalise, but it spends server time per view and adds to TTFB.
What is ISR (Incremental Static Regeneration)?
ISR serves a statically generated page but regenerates it in the background after a revalidation interval or an on-demand trigger. Users get static-file speed while the content refreshes without a full redeploy, which suits pages that change occasionally, like catalogues or articles.

Want this applied to your stack, not just defined?

The free tools run the numbers; an audit tells you where the real cost and risk are. Book a call, or leave your email and I'll reach out.

Book a call

No spam. You'll get a reply from me.

Prefer proof first? See how this plays out in real case studies →