Master the four core rendering strategies — CSR, SSR, SSG, ISR — and Streaming SSR. Know when to use each, how they affect SEO and performance, and how to confidently answer any rendering question in a frontend system design interview.
Imagine running a restaurant. CSR is handing customers a raw recipe — they cook at home with their device. SSR is cooking to order — a hot plate per request, always fresh, but the kitchen is always busy. SSG is a pre-made buffet — every plate identical, served instantly. ISR is a buffet that quietly replaces cold dishes in the background while guests are already eating, without closing the kitchen.
The browser receives an almost-empty HTML shell and a JavaScript bundle. React mounts and renders the UI after the bundle downloads, parses, and executes. This means:
// What Googlebot sees immediately for a CSR app
<html>
<body>
<div id="root"></div> <!-- empty until JS runs -->
<script src="/bundle.js"></script>
</body>
</html>Best for: authenticated dashboards, admin panels, highly interactive tools. Personalized content where pre-rendering adds no value.
Worst for: SEO-critical marketing pages, e-commerce product pages, anything that needs fast First Contentful Paint.
The server runs your React component tree and sends complete HTML. The browser displays content immediately, then React "hydrates" — attaches event listeners to the existing HTML without re-rendering.
// Next.js SSR — runs on every request
export async function getServerSideProps(context) {
const data = await fetchLiveData(context.params.id);
return { props: { data } };
}
// HTML is fully populated before it reaches the browserBest for: pages with frequently changing data (news, stock prices), personalized pages that still need SEO, anything requiring request-time cookies or headers.
Cost: higher TTFB, server must be running and scaling, no CDN caching of the HTML itself.
React runs at build time. The output is a collection of HTML files — no server needed at runtime. Pages are served from a CDN with near-zero latency.
// Next.js SSG — runs once at build time
export async function getStaticProps() {
const data = await fetchData(); // called at build, not at request time
return { props: { data }, revalidate: false };
}
export async function getStaticPaths() {
const slugs = await getAllSlugs();
return { paths: slugs.map(s => ({ params: { slug: s } })), fallback: false };
}Best for: blogs, docs, marketing pages, anything where content doesn't change between deploys.
Pages are statically generated at build time but can be regenerated in the background after a set interval. The first visitor after the stale period triggers a background regeneration — they still see the old page; the next visitor sees the new one.
export async function getStaticProps() {
const data = await fetchData();
return {
props: { data },
revalidate: 3600, // regenerate at most every 1 hour
};
}Best for: e-commerce (prices/inventory update hourly), news sites, product pages. The sweet spot between SSG speed and SSR freshness.
Instead of waiting for the full page to render server-side, the server streams HTML in chunks using Suspense boundaries. Above-the-fold content arrives immediately; slower sections (comments, recommendations) stream in later. This improves TTFB dramatically for data-heavy pages.
// React 18 Streaming with Suspense
export default function Page() {
return (
<div>
<Hero /> {/* fast — renders immediately */}
<Suspense fallback={<Spinner />}>
<SlowDataSection /> {/* streamed after slow data resolves */}
</Suspense>
</div>
);
}Ask three questions: (1) Does this page need SEO? If no → CSR is fine. (2) How often does the data change? If rarely → SSG. If hourly → ISR. If per-request → SSR. (3) Is the content personalized to the user? If yes → CSR or SSR.
CSR can't be indexed by Google — Googlebot does execute JavaScript and can index CSR content, but it's slower and less reliable than pre-rendered HTML. For critical SEO pages, don't rely on it.
SSR always beats SSG for SEO — SSG pages are often better because they respond in milliseconds from a CDN with no server-side delay. Google values page speed as a ranking signal.
ISR and SSG are the same thing — SSG is fixed at build time; ISR regenerates deployed pages in the background without a rebuild. They're architecturally different.
Hydration is free — SSR sends HTML but the browser still downloads and runs the full JS bundle to attach event listeners. This 'hydration cost' can cause poor TTI even when FCP is fast.
You must pick one strategy for the whole app — Next.js and similar frameworks let you mix strategies per page: marketing pages as SSG, dashboard as CSR, product pages as ISR.
Next.js e-commerce (Vercel, Shopify): product pages use ISR with revalidate: 3600 — inventory updates hourly without full rebuilds, CDN serves static HTML instantly
News sites (The Guardian, BBC): SSR for breaking news pages where freshness matters more than caching, CSR for comment sections that don't need SEO
Documentation sites (Next.js docs, Tailwind CSS): pure SSG — content changes only on deploy, CDN delivery is near-instant globally
Authenticated SaaS dashboards (Vercel, Linear): CSR — content is user-specific, no SEO benefit from pre-rendering, full interactivity needed
React 18 streaming on large pages: Vercel uses Suspense streaming for their dashboard to show the shell immediately while data-heavy sections stream in
What is the difference between CSR, SSR, SSG, and ISR?
When would you choose SSR over SSG for a page?
What is Streaming SSR and how does it improve perceived performance?
What is hydration and what causes hydration mismatches?
What is partial hydration / islands architecture and why does it matter?
What are the SEO implications of CSR vs SSR?
Reading answers is not the same as knowing them. Practice saying them out loud with AI feedback — that's what builds real interview confidence.