Loading...
Loading...
How code becomes pixels. Every rendering strategy explained.
Module 1 · Rendering Strategies
How HTML gets generated and delivered to the browser: CSR, SSR, SSG, ISR, Streaming, Hydration, Islands Architecture, and React Server Components.
Rendering is how code becomes HTML in the browser. This chapter covers every strategy — CSR, SSR, SSG, ISR, Streaming SSR, Hydration, Islands Architecture, and React Server Components — with trade-off tables and scenario-based guidance for picking the right approach.
Rendering strategy is the first architectural decision in any frontend system — it shapes SEO, time-to-first-byte, JavaScript bundle size, server cost, and how much interactivity happens on the client vs the server.
SDE-2 interviews expect you to compare CSR, SSR, SSG, and ISR with concrete trade-offs, explain hydration and partial hydration, and describe how React Server Components and streaming SSR change the traditional model.
This module covers each strategy with flow diagrams, performance metrics (FCP, LCP, TTFB, TTI), scenario-based recommendations, and interview questions so you can defend your rendering choices under pressure.
You will leave knowing when to pick CSR for dashboards, SSR for SEO-critical pages, SSG for docs, ISR for semi-static content, and how Islands Architecture and RSC reduce client JavaScript without sacrificing interactivity.
Choosing the right rendering strategy determines your app's performance, SEO ranking, server costs, and user experience. Modern frameworks like Next.js combine multiple strategies — understanding each is essential. Interviewers often ask why you would not SSR everything or when RSC eliminates client-side JavaScript entirely.
The process of converting application code into HTML that the browser can display.
Rendering is the process of converting application code and data into HTML that can be displayed in the browser.
A rendering strategy determines:
| Where | HTML is generated (server, browser, or build) |
| When | HTML is generated (request time, build time, background) |
| Data | How data is fetched and injected |
| Performance | Initial load speed, interactivity, bundle size |
| SEO | Whether search engines can index the content |
Every rendering strategy is a combination of WHERE and WHEN HTML is produced.
Instead of memorizing acronyms, think in two independent axes. Where is HTML generated — on the server, in the browser, or ahead of time at build? When is it generated — on every request, once at deploy, or lazily in the background?
CSR = browser + runtime. SSR = server + per request. SSG = build + deploy. ISR = build + background refresh. Modern apps mix all four on different routes or even different sections of the same page.
| Strategy | Where | When |
|---|---|---|
| CSR | Browser | After JS downloads & runs |
| SSR | Server | On each request |
| SSG | Build machine | At deploy time |
| ISR | Build + server | Deploy + background regen |
| Streaming SSR | Server | Incrementally per request |
| RSC | Server | Per request (no client JS shipped) |
Interview insight
When asked “CSR vs SSR,” clarify whether the question is about initial HTML (SEO, FCP) or interactivity (TTI, bundle size). SSR solves the first; hydration and client components solve the second. They are related but not the same problem.
The browser downloads JavaScript and renders the page on the client side.
In CSR, the server sends a minimal HTML shell — often just <div id="root"></div> plus script tags. The browser must download JavaScript, parse it, execute React (or Vue/Angular), fetch data from APIs, and only then paint meaningful content. The user stares at a blank or spinner screen during this gap.
After the first load, CSR shines: route changes happen client-side without full page reloads. That is why SPAs like Gmail and Notion feel fast after you are logged in, even though the first visit can feel slow.
What the user experiences
Blank page
HTML shell arrives — no visible content yet
JS downloading
Browser fetches bundle(s); user still sees spinner
JS executing
Framework bootstraps, may fire API requests
Content appears
Data returns, UI renders — FCP and LCP happen late
Advantages
Disadvantages
Why CSR has SEO limitations
Best Use Cases
HTML is generated on the server for every incoming request.
SSR generates complete HTML on the server for every request. When the browser receives the response, it can paint text and images immediately — before any JavaScript runs. That is why SSR improves FCP and SEO: crawlers and users see real content in the first byte stream.
But SSR alone does not make the page interactive. The server sends static HTML; the browser still must download JavaScript and hydrate it before buttons work. SSR trades faster visible content for higher server work and often slower TTFB (the server must fetch data and render before sending anything).
What the user experiences
Request sent
User navigates; server starts fetching data
TTFB
First HTML bytes arrive — user sees content quickly
FCP / LCP
Full HTML painted; page looks complete but is not interactive
Hydration complete
JS loaded; buttons and forms become interactive (TTI)
Advantages
Disadvantages
Best Use Cases
HTML is generated once during build time and served as static files.
SSG pre-renders every page at build time (`next build`). The output is plain HTML/CSS/JS files uploaded to a CDN. When a user requests a page, the CDN returns a cached file instantly — no server computation, no database query at request time.
The trade-off is freshness: content is frozen until the next deploy (unless you add ISR). For docs, blogs, and marketing sites where content changes infrequently, SSG is the fastest and cheapest option.
Advantages
Disadvantages
Best Use Cases
Pages are statically generated but can be regenerated in the background after a specified interval.
ISR is SSG with a freshness window. You set a revalidation interval (e.g. 60 seconds). The first request after expiry still gets the stale cached page instantly — then the server regenerates the page in the background. The next visitor gets the fresh version.
This pattern powers large catalogs (millions of product pages) without rebuilding the entire site on every price change. The user may briefly see stale data — acceptable for most e-commerce listings, unacceptable for stock tickers or live scores.
Advantages
Disadvantages
Best Use Cases
Instead of waiting for the entire page, the server streams HTML chunks as soon as they are ready.
Classic SSR waits until every component finishes before sending any HTML. If one slow database query blocks the page, the user waits. Streaming SSR sends HTML in chunks as each section completes — header first, then main content, then slow widgets like comments or recommendations.
React Suspense boundaries define these chunks. While a section loads, the server sends a lightweight fallback (skeleton UI). The browser paints progressively, so FCP improves even when total render time is unchanged.
// Suspense marks a streaming boundary <Suspense fallback={<CommentsSkeleton />}> <Comments /> {/* slow DB query */} </Suspense> // Header + article HTML arrives first; // comments stream in when ready
Advantages
Disadvantages
Best Use Cases
Attaches JavaScript event handlers to server-rendered HTML, making it interactive.
Hydration converts static HTML into interactive UI by attaching JavaScript event handlers to the DOM elements already rendered by the server.
Before Hydration
<!-- Before hydration — static HTML --> <button>Buy Now</button> <!-- Looks right, but no click handler yet -->
The HTML is rendered but has no JavaScript attached. Clicking does nothing.
When server-rendered HTML differs from what React generates on the client.
A hydration mismatch occurs when the HTML generated on the server differs from what React generates on the client. React detects the difference and re-renders, which hurts performance.
Server renders
<span>10:00 AM</span>
Client renders
<span>10:01 AM</span>
Common Causes
Only interactive components are hydrated instead of the entire page.
Advantages
Disadvantages
Static HTML ocean with small interactive component islands.
Advantages
Disadvantages
React 18+ prioritizes hydrating interactive regions before the rest of the page.
Traditional hydration is all-or-nothing: the browser hydrates the entire component tree before any interaction works. Selective hydration lets React hydrate high-priority regions first — for example, the search box the user clicked while the rest of the page is still hydrating in the background.
Combined with Streaming SSR, this closes the gap between “looks ready” and “feels ready.” The page paints early (streaming), and the part the user cares about becomes interactive first (selective hydration).
How it differs from Partial Hydration / Islands
Partial hydration and Islands skip hydration entirely for static regions. Selective hydration still hydrates everything — but reorders the work based on user input and Suspense boundaries.
Components that execute on the server and send rendered output — not their JavaScript — to the client.
// This component runs on the server only // Its JavaScript is NEVER sent to the browser async function Product() { const product = await db.products.find(); return <div>{product.name}</div>; }
Advantages
Disadvantages
Server vs Client Components
Server Component
Data fetching, DB access, no JS shipped
Client Component
useState, onClick, browser APIs
Server Components cannot use
useState() // ✗ No state useEffect() // ✗ No effects useReducer() // ✗ No reducers onClick // ✗ No event handlers
Because they execute on the server — no browser environment exists.
Use Client Components when you need
The key metrics affected by your rendering strategy choice.
Interactive · Rendering strategy timeline
Empty shell first, then JS download, render, hydrate.
Time until first visible content appears on screen.
Improved by: SSR, SSG, Streaming
Time until the largest visible element is rendered.
Improved by: SSR, SSG, ISR
Time until the browser receives the first byte from the server.
Improved by: SSG, CDN, Edge
Time until the page becomes fully interactive (responds to input).
Improved by: Partial Hydration, Islands, RSC
SSR Improves
SSR Can Worsen
How each rendering strategy stacks up.
| Strategy | Rendered At | SEO | Initial Load | Server Cost |
|---|---|---|---|---|
| CSR | Browser | Poor | Slow | Low |
| SSR | Server | Excellent | Fast | High |
| SSG | Build Time | Excellent | Very Fast | Very Low |
| ISR | Build + BG | Excellent | Very Fast | Medium |
| Streaming SSR | Server | Excellent | Fast | High |
| Islands | Mostly Static | Excellent | Very Fast | Low |
| RSC | Server | Excellent | Fast | Medium |
How to choose rendering strategies for real applications.
| Page | Strategy | Reason |
|---|---|---|
| Product Listing | ISR | SEO required, data changes occasionally |
| Product Detail | ISR | High traffic, content updates periodically |
| Shopping Cart | CSR | User-specific data, no SEO needed |
| Checkout | SSR | Dynamic inventory & pricing validation |
Decision Framework
Choose SSR when data changes per request, content is personalized, or auth is required.
Choose SSG when content rarely changes, SEO matters, and traffic is high.
Choose ISR when you need SSG speed but content updates periodically.
Choose CSR for authenticated, user-specific, highly interactive pages.
If SSR improves SEO and initial load, why not use it for everything?
SSR Improves
SSR Costs
SSR doesn't help when
Key Insight
There is no universally best rendering strategy. The optimal choice depends on SEO requirements, content freshness, personalization needs, traffic patterns, and infrastructure constraints.
For millions of pages
Pure SSR is too expensive at scale — combine strategies.
How Next.js combines multiple rendering strategies into one flow.
Modern Next.js doesn't pick a single rendering strategy — it combines React Server Components, Streaming SSR, and Selective Hydration so each part of the page uses the best strategy automatically.
Server Components handle data fetching and static content. Client Components are streamed and hydrated only where interactivity is needed. The result is smaller bundles, faster loads, and excellent SEO — all in one framework.
Common questions about rendering strategies.