CSR vs SSR vs SSG vs ISR

Explained the Way a System Designer Thinks

The problem we’re solving

When users open a webpage, something somewhere has to turn data into HTML.

That “somewhere” could be:

the browser
the server
the build pipeline
or a background regeneration system

All rendering strategies—CSR, SSR, SSG, ISR—are simply different answers to one question:

When, where, and at what cost should HTML be produced?

Once you see this, the topic stops being confusing.

Start from the simplest mental model

Imagine this pipeline:

Data → HTML → User

The only thing that changes across strategies is who performs this transformation and when it happens.

Client-Side Rendering (CSR):

“HTML is created inside the browser”

Screenshot 2026-01-27 004320.png

With CSR, the server does almost nothing beyond serving files.

What the user initially receives is:

a mostly empty HTML file
a large JavaScript bundle

Only after JavaScript loads and executes does the browser:

fetch data from APIs
convert that data into HTML
paint the UI

From a system perspective, this is a massive architectural decision.

You are saying:

“Every user device is now a rendering engine.”

Why this exists in real systems

CSR became popular because:

servers are expensive
browsers are powerful
APIs scale better than templated servers

This is why internal dashboards, admin panels, and authenticated apps love CSR.

Once the JS is cached:

navigation feels instant
data updates dynamically
server costs stay low

But here’s the hidden cost

CSR fails silently.

If:

JS fails to load
the device is slow
the network is poor

The user sees nothing.

From a system designer’s view:

CSR pushes failure to the edge
The backend looks healthy while UX collapses

CSR is not bad, its selective responsibility shifting.

Server-Side Rendering (SSR):

“HTML is created per request on the server”

SSR moves rendering back to the server.

Now the pipeline looks like this:

Request → Server fetches data → Server renders HTML → User

The user immediately receives meaningful HTML, even before JavaScript runs.

Why systems choose SSR

SSR is chosen when:

ontent must be fresh
output depends on user identity
SEO matters

For example:

logged-in landing pages
personalized home feeds
role-based content

From a correct standpoint, SSR is excellent.

The trade-off most teams underestimate

SSR introduces request-time computers.

Every request:

hits the server
executes rendering logic
consumes CPU and memory

This means:

traffic spikes become dangerous
cold starts hurt performance
caching is complicated

A system designer sees SSR as:

“High correctness, high operational risk.”

It’s powerful, but expensive at scale.

Static Site Generation (SSG):

“HTML is created before users exist”

SSG changes the timeline entirely.

Instead of rendering at request time, the system renders at build time.

So the flow becomes:

Build pipeline → Render HTML → Store on CDN → Serve instantly

At runtime:

there is no server logic
no database access
no computation

Just files.

Why SSG is so powerful

SSG is why modern documentation sites and blogs feel “instant”.

Because:

CDN latency is tiny
HTML is precomputed
failures are rare

From a system perspective:

SSG has near-infinite scalability
costs are predictable
performance is unbeatable

Where SSG breaks down

SSG assumes:

“Data does not change often.”

If your content:

updates frequently
depends on real-time state
must always be accurate

Then SSG becomes painful:

rebuilds grow longer
deploys happen constantly
content becomes stale

SSG is not dynamic, it is strategically static.

Incremental Static Regeneration (ISR):

“Static pages with controlled freshness”

ISR exists because real systems live between two extremes:

“Always fresh” (SSR)
“Always static” (SSG)

ISR introduces a new idea:

Serve static HTML first, then fix it later if needed.

The user always gets a fast response.

If the content is stale:

regeneration happens in the background
the next user gets updated HTML

This is a system-level compromise.

Why ISR works in production

ISR is ideal when:

data changes every few minutes or hours
brief staleness is acceptable
traffic spikes are unpredictable

This is why:

product pages
content platforms
news sites

love ISR.

The cost of ISR (and it’s real)

ISR introduces eventual consistency.

That means:

two users may see slightly different data
cache invalidation becomes a real concern
correctness must be defined carefully

ISR doesn’t remove complexity, it moves it into time.

How system designers think about this

They don’t ask:

“Which rendering method should we use?”

They ask:

Where should computation live?
Where is failure acceptable?
How fresh does data need to be?
What happens during traffic spikes?

And the answer is almost always: use multiple strategies.

Why frameworks like Next.js exist

Not to simplify React.

But to let teams:

mix rendering strategies per route
control caching explicitly
treat frontend as part of system architecture

Modern frontend frameworks are orchestration layers, not UI tools.

Final mental model (this is the takeaway)

CSR, SSR, SSG, and ISR are not rendering techniques, they are ways of distributing computation across time, infrastructure, and users.

Once you think like this, the confusion disappears.