SSR vs SSG vs ISR

The problem

Discussions about SSR, SSG, and ISR often go wrong because they turn into framework religion too early.

The result is a pile of confident but not very useful lines:

• “SSR is better for SEO”
• “SSG is always faster”
• “ISR solves everything”

Each sentence touches one part of the truth.

None of them is enough to make a good decision.

Mental model

The main difference between these strategies is:

when the HTML is ready and how fresh it needs to be when the user asks for the page.

In very direct terms:

• SSG: generate ahead of time and serve it ready
• SSR: generate on request
• ISR: serve static output but regenerate in controlled windows

That creates trade-offs around:

• speed
• cache
• server cost
• content freshness
• invalidation complexity

Breaking the problem down

SSG

SSG works well when content changes rarely or can tolerate update delay.

Advantages:

• cheap delivery
• simple caching
• HTML ready early

Costs:

• rebuild or republish to reflect updates
• less freshness when content changes quickly

Great for:

• marketing pages
• docs
• editorial content

SSR

SSR generates HTML per request.

Advantages:

• fresh content
• the ability to personalize by request

Costs:

• more work on every request
• infrastructure and cache become more sensitive
• risk of worse TTFB if the page depends too much on slow fetches

Good for:

• pages that depend on user context
• dynamic content that needs to reflect recent state

ISR

ISR tries to sit in the middle:

• serve a static page
• revalidate on windows or events

Advantages:

• lower cost than pure SSR in many cases
• better freshness than pure SSG

Costs:

• invalidation needs to be understood
• the data is not always the newest possible
• the team needs to know when temporary staleness is acceptable

The point many people forget

Choosing between SSR, SSG, and ISR does not solve by itself:

• expensive hydration
• too much JavaScript
• heavy client components

You can have SSR and still deliver a bad experience if the client stays stuck afterward.

So this choice affects performance, but it does not replace the rest of the work.

Simple example

Imagine three pages:

1. an editorial homepage
2. a product catalog updated many times a day
3. a personalized user dashboard

A mature read would be:

• the editorial homepage fits well with SSG
• the catalog may fit ISR if it can tolerate a small staleness window
• the dashboard likely needs SSR or another clearly dynamic strategy

That answer is better than:

“Our framework supports ISR, so we should use ISR for everything.”

Common mistakes

• Choosing the strategy because of framework hype.
• Treating SEO as the only criterion.
• Assuming SSG is always faster in every sense.
• Ignoring cache and invalidation when talking about ISR.
• Confusing early HTML with early interactivity.

How a senior thinks

People who think well about this usually structure the decision like this:

• how often does the content change?
• how expensive is it to serve this per request?
• how much staleness can I tolerate?
• does cache help or hurt here?
• does the page need per-user context?

That moves the conversation away from slogans and into product, operations, and cost.

Seniority here means knowing that rendering is a system decision, not stack decoration.

What the interviewer wants to see

They want to see whether you:

• understand when HTML is generated in each strategy
• can talk about freshness, cache, and cost
• do not confuse initial render with interactivity
• choose based on context instead of dogma

If you say something like “SSG serves me well when content is stable, SSR helps when I need freshness per request, and ISR fits when I want to amortize cost with controlled updates,” that is already a strong answer.

Good rendering decisions come from clear trade-offs, not loyalty to a framework.

The best strategy is the one that delivers the right HTML at the right moment for an acceptable cost.