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 more nuanced 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): ship a JS bundle; render in the browser. Slow first paint, fast SPA navigation.
- SSR (server-side rendering): render on each request. Fresh content; slower TTFB.
- SSG (static site generation): render at build time. Fastest delivery; stale unless rebuilt.
- ISR (incremental static regeneration): static + on-demand revalidation. Next.js popularized.
- PPR (partial prerendering): Next 14+. Render shell statically; stream dynamic parts.
- RSC (React Server Components): components that run only on the server; 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 cost: server compute scales with traffic; provisioning matters
- SSG build time: 100K pages = long builds; ISR or SSR is more practical at scale
- CSR JS bundle: ships everything; LCP suffers; mobile users feel it
- RSC complexity: the mental model is non-trivial; 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.