In React and frontend system design interviews, rendering strategy means how HTML is generated and delivered to the browser. Choosing the right strategy directly impacts SEO, performance, interactivity, and cost.
- Quick Reference
- Client Side Rendering (CSR)
- Server Side Rendering (SSR)
- Static Site Generation (SSG)
- Incremental Static Regeneration (ISR)
- Streaming Rendering
- Edge Rendering
- How Real Apps Combine Strategies
- Decision Framework
- Interview Answers
| Strategy | SEO | Speed | Dynamic Data | Best For |
|---|---|---|---|---|
| CSR | ❌ | Slow first load | ✅ Full | Dashboards, tools |
| SSR | ✅ | Fast first paint | ✅ Per request | Social feeds, news |
| SSG | ✅ | Fastest | ❌ Build time only | Blogs, docs, marketing |
| ISR | ✅ | Fast | ✅ Periodic | E-commerce, large sites |
| Streaming | ✅ | Best perceived | ✅ Chunked | Complex pages, slow APIs |
| Edge | ✅ | Lowest latency | ✅ | Global apps, personalization |
The server sends a minimal HTML shell and a JS bundle. React runs entirely in the browser and renders the UI.
Server → index.html + bundle.js
Browser → React mounts and renders UI
<!-- What the server sends -->
<div id="root"></div>
<script src="bundle.js"></script>// React takes over in the browser
import { createRoot } from "react-dom/client";
const root = createRoot(document.getElementById("root"));
root.render(<App />);| Pros | Cons |
|---|---|
| Highly interactive | No SEO out of the box |
| Low server cost | Slow initial load (large JS bundle) |
| Great for complex UI | Empty page until JS executes |
SEO doesn't matter, and the app requires heavy client-side interaction.
- Gmail — complex interaction, no SEO needed
- Google Docs — real-time collaborative editing
- Figma — canvas-based design tool
- CodeSandbox — in-browser IDE
- Internal dashboards, admin panels
The server renders a full HTML page for each request. React then hydrates it in the browser to attach interactivity.
Request → Server renders HTML → Browser displays page → React hydrates
// Next.js (Pages Router)
export async function getServerSideProps() {
const res = await fetch("https://api.example.com/posts");
const posts = await res.json();
return { props: { posts } };
}| Pros | Cons |
|---|---|
| Great SEO | Higher server cost |
| Fast first paint | Slower TTFB under heavy load |
| Works without JS initially | Needs caching strategy |
SEO is critical and content changes frequently (per user or per request).
- Twitter / X — tweet pages indexed by Google
- Reddit — SEO-driven content discovery
- LinkedIn — profile pages, job listings
- News websites — articles need to be crawled
Pages are pre-rendered at build time and served from a CDN. No server rendering at runtime.
Build → Generate all HTML → Deploy to CDN → Serve instantly
// Next.js (Pages Router)
export async function getStaticProps() {
const res = await fetch("https://api.example.com/posts");
const posts = await res.json();
return { props: { posts } };
}| Pros | Cons |
|---|---|
| Fastest possible load | Stale if content changes often |
| Cheap hosting (CDN) | Requires full rebuild to update |
| Excellent SEO | Not suitable for user-specific content |
Content changes rarely or never changes between deployments.
- Next.js docs — documentation sites
- Vercel blog — marketing and blog pages
- Portfolio websites — personal sites
- Dev.to article pages — largely static content
A hybrid of SSG and SSR. Pages are statically generated at build time but revalidated in the background after a set interval — no full rebuild needed.
// Next.js
export async function getStaticProps() {
const res = await fetch("https://api.example.com/posts");
const posts = await res.json();
return {
props: { posts },
revalidate: 60, // Regenerate this page at most once every 60 seconds
};
}Behavior: After the revalidation window, the next request triggers a background regeneration. Visitors always get a cached page — the update arrives on the subsequent request.
| Pros | Cons |
|---|---|
| Fast like SSG | Data can be slightly stale |
| Content stays fresh without full rebuild | Revalidation adds backend complexity |
| Scales to millions of pages | Not suitable for real-time data |
Large sites where content updates periodically but doesn't need to be real-time.
- Amazon product pages — inventory, pricing change regularly
- Shopify stores — product catalog updates
- E-commerce category pages — millions of pages, periodic updates
- News sites — articles update but not every second
Introduced in React 18, streaming sends HTML to the browser in chunks as it becomes ready — instead of waiting for the full page to render.
Server → sends <head> immediately
Server → sends above-the-fold content
Server → sends slower sections as data arrives
// Node.js server
import { renderToPipeableStream } from "react-dom/server";
renderToPipeableStream(<App />, {
onShellReady() {
res.setHeader("Content-Type", "text/html");
pipe(res); // Start streaming immediately
},
});// Wrap slow sections in Suspense
<Suspense fallback={<Spinner />}>
<Comments /> {/* Streams in when data is ready */}
</Suspense>| Pros | Cons |
|---|---|
| Best perceived performance | More complex to implement |
| Faster Time to First Byte | Requires careful Suspense boundaries |
| Independent sections don't block each other | Not supported in all environments |
Pages with multiple independent sections that fetch data at different speeds.
- Facebook — different content sections load independently
- LinkedIn — feed and sidebar load in parallel
- Large dashboards — widgets stream in as data arrives
Pages are rendered on edge servers — CDN nodes distributed globally, close to the user — rather than in a central data center.
User (Mumbai) → Edge server (Mumbai) → Rendered HTML in ~10ms
User (London) → Edge server (London) → Rendered HTML in ~10ms
vs.
User (Mumbai) → Central server (US) → Rendered HTML in ~200ms
// Next.js Edge Runtime
export const runtime = "edge";
export default function Page() {
return <div>Rendered at the edge</div>;
}Providers: Next.js Edge Runtime, Cloudflare Workers, Vercel Edge Functions
| Pros | Cons |
|---|---|
| Very low latency globally | Limited Node.js API support |
| Scales automatically | Cold starts on some platforms |
| Supports personalization at low cost | Debugging is harder |
Global apps where personalization and low latency both matter.
- Global e-commerce storefronts
- SaaS dashboards with international users
- Personalized landing pages (A/B testing, geolocation)
Production apps never use a single rendering strategy. They mix strategies per page based on requirements.
Strategy: SSR + CSR + Streaming
| Page / Section | Strategy | Why |
|---|---|---|
| Landing page | SSR | SEO + fast initial load |
| Movie detail page | SSR | Indexed by Google |
| Recommendations row | CSR | Personalized per user |
| Continue Watching | CSR | User-specific |
| Video player UI | CSR | Heavy interaction |
Flow:
Request → SSR renders shell + movie metadata
→ Browser shows page fast
→ React hydrates
→ CSR API calls load personalized rows
Strategy: SSR + CSR
| Page / Section | Strategy | Why |
|---|---|---|
| Homepage | SSR | SEO + fast load |
| Video watch page (metadata) | SSR | Title/description indexed by Google |
| Comments | CSR | Infinite scroll, dynamic |
| Recommendations sidebar | CSR | Personalized |
| Video player | CSR | Real-time interaction |
Strategy: SSR + CSR
| Page / Section | Strategy | Why |
|---|---|---|
| Login | CSR | No SEO needed |
| Profile page | SSR | Indexed by Google for recruiting |
| Feed | CSR | Constantly updating |
| Notifications | CSR | Real-time polling / WebSocket |
| Jobs page | SSR | SEO for job seekers |
Strategy: SSR + SSG + ISR
| Page / Section | Strategy | Why |
|---|---|---|
| Product page | SSR | SEO for millions of products |
| Category page | ISR | Updated periodically, cached |
| Deals page | ISR | Refreshes on a schedule |
| Checkout | CSR | User-specific, no SEO needed |
| Reviews | CSR | Loaded dynamically |
Strategy: SSR + CSR + Streaming
| Page / Section | Strategy | Why |
|---|---|---|
| Tweet page | SSR | Indexed by Google / social cards |
| Home feed | CSR | Constantly updating |
| Notifications | CSR | Real-time |
| Trending | SSR | SEO-driven |
Strategy: Pure CSR + WebSockets
No SEO required. The entire app is a heavy client-side experience with real-time collaboration over WebSockets.
Browser loads index.html
→ React mounts
→ Document content fetched via API
→ WebSocket connection opens
→ Real-time edits sync across clients
Use this tree when deciding on a rendering strategy:
Does it need SEO?
├── No → CSR
│ (dashboards, design tools, internal apps)
└── Yes → Does content change per request?
├── Yes → SSR
│ (social feeds, news, search results)
└── No → Does it change periodically?
├── Yes + large site → ISR
│ (e-commerce, news archives)
└── No → SSG
(blogs, docs, marketing pages)
Also consider:
├── Page has slow/independent sections? → Add Streaming
└── Global audience + personalization? → Edge Rendering
"I choose rendering strategies based on three factors: SEO requirements, how dynamic the content is, and the scale of the site. CSR for app-like tools with no SEO needs, SSR for SEO-critical dynamic content, SSG for static pages, and ISR when you need SSG-level speed but with periodic updates."
"Most production apps combine strategies per page. Netflix uses SSR for movie pages so they're indexed by Google, while recommendations load via CSR because they're personalized. Amazon uses ISR for category pages to scale to millions of URLs without rebuilding on every deploy. For pages with independent slow sections, I'd layer in Streaming with React 18 Suspense boundaries so users see content progressively rather than waiting for the slowest data source."
"SSR improves SEO and first paint, but it increases TTFB under load and requires a caching strategy. ISR gives you SSG-level speed with fresher data, but it means some users briefly see stale content. The right choice always depends on what you're optimizing for — user perception, crawlability, or server cost."