# SSR vs CSR vs SSG vs ISR: The 2026 Frontend Tradeoff

Source: https://www.techinterview.org/post/3233475388/ssr-csr-ssg-isr-2026-frontend-tradeoff/
Updated: 2026-07-12 · techinterview.org

The acronyms keep multiplying: SSR, CSR, SSG, ISR, RSC, PPR, DSC. Senior frontend interviews probe whether you can articulate which rendering strategy fits which problem and why. The 2026 answer is less clear-cut than "always SSR" or "everything static." This guide is a working developer's framing of the real tradeoffs.

## The strategies, briefly

- CSR (client-side rendering) ships a JS bundle and renders in the browser. Slow first paint, fast SPA navigation.

- SSR (server-side rendering) renders on each request. Fresh content, slower TTFB.

- SSG (static site generation) renders at build time. Fastest delivery, stale unless rebuilt.

- ISR (incremental static regeneration) is static + on-demand revalidation. Next.js popularized it.

- PPR (partial prerendering), Next 14+, renders the shell statically and streams the dynamic parts.

- RSC (React Server Components) run only on the server and interleave with client components.

## What the user cares about

- How fast does the page first appear?

- How interactive is it once it appears?

- Is the content fresh enough?

- Does it feel "snappy" once they are using it?

The rendering strategy is in service of these. Pick by what you optimize for.

## The actual decision tree

### Public, mostly-static content (marketing, blog, docs)

- SSG by default: fastest delivery, lowest cost, best SEO

- ISR if updates are frequent (daily blog posts, doc updates)

- Examples: Vercel's own marketing site, Linear's docs, technote / blog

### Logged-out e-commerce / catalog

- SSG / ISR for catalog pages (regenerate when products change)

- SSR for personalized pages (recommendations, recently viewed)

- PPR is a strong fit: static shell + dynamic personalization

### Logged-in product (dashboards, SaaS)

- CSR for the most interactive parts

- SSR for the initial shell (faster perceived load)

- RSC for data-fetching components without ballooning the JS bundle

- Streaming SSR with Suspense for perceived-fast loads

### Real-time apps (chat, collaboration)

- CSR for the live state

- SSR / streaming SSR for the initial shell

- WebSocket for live updates after hydration

### News / content with high freshness needs

- SSR with edge caching

- Or ISR with short revalidate windows

- Headers for CDN to cache for a few seconds

## The hidden costs

- SSR's server compute scales with traffic, so provisioning matters.

- SSG build time scales with page count; 100K pages = long builds, so ISR or SSR is more practical at scale.

- CSR ships the whole JS bundle; LCP suffers, and mobile users feel it.

- RSC adds complexity; the mental model is non-trivial, and the team needs to learn it.

## SEO considerations

- SSG and SSR both work for crawlers; modern Google handles CSR but with delay

- For fast-changing content, SSR or ISR with short windows

- SSG with revalidation is Google-friendly because pages are always available

## Streaming SSR

Modern Next.js, Remix, SvelteKit support streaming the HTML response:

- Server starts sending HTML before all data is ready

- React Suspense boundaries determine streaming chunks

- User sees critical content fast; below-fold streams in

- TTFB drops; LCP improves

## The hydration question

- Hydration = attaching JS event handlers to server-rendered HTML

- Cost: full JS download and parse before page is interactive

- Mitigation: progressive hydration (Astro's islands), selective hydration (React 18+), RSC (much less JS shipped)

## Edge rendering

- Edge runtime executes the server-render close to the user (Cloudflare Workers, Vercel Edge)

- Big perf win when the data is also available at the edge

- Loses if you must call origin DB from edge; round-trip dominates

- 2026 best practice: hybrid (edge for shells, regional for data-heavy paths)

## The 2026 default for new SaaS

If you are starting a new project today and you do not have specific reasons to deviate:

- Next.js App Router (or Remix / SvelteKit / Nuxt for those ecosystems)

- RSC for data-fetching components

- Streaming SSR for dynamic pages

- SSG for marketing pages

- Edge runtime for the shell; regional for data

This is the "boring" choice and it is correct for most apps.

## What interviewers reward

- Specific framing of the trade, not "SSR good, CSR bad"

- Recognition that hybrid is the modern default

- Discussion of bundle size as a perf concern

- Mentioning streaming, RSC, PPR with calibrated views

- "It depends on the app" — but with reasoning, not as a dodge

## Common interview questions

- "You are building [type of app]. Which rendering strategy?"

- "Walk me through hydration. What is the cost? How do you minimize it?"

- "What is the difference between RSC and traditional SSR?"

- "How do you decide between ISR and SSR for a content page?"

## What separates senior from staff

Senior candidates can match strategies to use cases. Staff candidates discuss the cost and complexity tradeoffs (operational, mental, financial). Principal candidates address the team-fit question: RSC is great if your team can adopt it, less so if you have a six-person team that ships product daily.

## Frequently Asked Questions

### Should I avoid CSR entirely in 2026?

No. Highly-interactive product surfaces are still CSR-heavy. The goal is "use SSR / RSC for the parts that benefit; keep CSR where the interaction lives."

### Is SSR fundamentally slower than SSG?

For first request to a given page, yes, server has to render. With aggressive edge caching the gap closes. ISR and PPR blend the two approaches.

### Are RSC ready for production?

Yes in Next.js (stable). Other frameworks are catching up. Adoption is real but not universal; pick based on your team's framework choice.