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.
Useful next steps:
