Frontend · interactive

CSR, SSR, SSG and ISR

Where and when is the HTML made? In the browser, on every request, once at build time, or at build time and then refreshed in the background. Each trades speed, freshness and server cost differently. The author fixes a typo; when do readers see it?

Client-side rendering1400 ms
Server-side rendering420 ms
Static generation160 ms
Incremental static regeneration160 ms

Grey: waiting for the first byte. Colour: until the article text is visible.

Server work: none
Build: slow (every page)
Freshness: only after a rebuild
SEO: good

A reader 30 s after the fix sees the old (until the next deploy) version.

Pages are pre-built HTML on a CDN: fastest and cheapest, but stale until the next build.

Rendering

Reader arrives after the fix30 s

Step 3 of 4 · read left to right

1
CSR: render in the browser
Good for app-like screens behind a login, where SEO doesn't matter.
Dashboards, editors.
2
SSR: render on each request
For personalised or constantly changing pages that must be crawlable.
Cache aggressively where you can.
3
SSG and ISR: render ahead
Docs, blogs, marketing and product pages. ISR or on-demand revalidation keeps them fresh without full rebuilds.
export const revalidate = 60
4
Choose per route
Modern frameworks let each page pick. Static shell plus streamed dynamic parts is increasingly common.
Next.js, Astro, Remix, Nuxt.

In production

Tools and technologies

Frameworks let each route choose how it renders.

Not tied to one language — use these names when you search docs or design a system.