Server-Side vs Client-Side Rendering
Understand server-side vs client-side rendering — where HTML is built, hydration, SEO impact, and trade-offs — with examples and interview questions.
Expected Interview Answer
Server-side rendering (SSR) builds the full HTML for a page on the server and sends it ready to display, while client-side rendering (CSR) sends a near-empty HTML shell plus JavaScript that builds the page in the browser after the scripts load and run.
With SSR, each request hits the server, which fetches data, renders the component tree to HTML, and returns a complete page the browser can paint immediately, then JavaScript "hydrates" it to attach interactivity. With CSR, the initial response is a small HTML file with a script tag; the browser downloads the JavaScript bundle, executes it, fetches data, and renders the DOM entirely on the client, so the first paint is delayed until the bundle runs. SSR generally wins on first-contentful-paint and SEO crawlability since content exists in the initial HTML; CSR generally wins on perceived speed for subsequent navigations because only data, not full markup, needs to be fetched. Modern frameworks blend both — SSR for the first load, client-side transitions afterward — to get the best of each.
- SSR gives faster first paint and crawler-visible content
- CSR reduces server load and gives snappy client-side navigation
- Hybrid rendering lets teams choose per-route trade-offs
- Both share the same component code in modern frameworks
AI Mentor Explanation
SSR is like a scoreboard operator who fully fills in the board in the dressing room before the gates open, so fans see the complete score the instant they walk in. CSR is like handing fans a blank board and a marker at the gate, making them copy every run themselves before it means anything. The pre-filled board gets useful information in front of eyes immediately, while the blank one needs work done first but can then be updated ball by ball without redrawing everything. That gap between ready-on-arrival and build-it-yourself is exactly SSR versus CSR.
Step-by-Step Explanation
Step 1
Request hits the server
For SSR, the server fetches data and renders full HTML per request; for CSR, it returns a minimal shell.
Step 2
Browser paints first content
SSR paints real content immediately; CSR paints a loading state until the JS bundle runs.
Step 3
JavaScript takes over
SSR hydrates existing markup with event listeners; CSR builds the entire DOM from scratch.
Step 4
Subsequent navigation
Both typically use client-side routing afterward, fetching only data for new views.
What Interviewer Expects
- Clear explanation of where HTML is built (server vs browser)
- Trade-offs: first-paint speed and SEO vs server load and interactivity cost
- Understanding of hydration as the bridge between SSR and CSR
- Awareness that modern frameworks combine both approaches
Common Mistakes
- Claiming CSR apps have no server involvement at all
- Ignoring hydration cost when praising SSR as strictly "faster"
- Confusing SSR with static site generation (build-time vs request-time)
- Assuming SEO is impossible with CSR (crawlers increasingly execute JS, but unreliably)
Best Answer (HR Friendly)
“Server-side rendering means the server builds the full webpage before sending it, so you see content right away. Client-side rendering means the browser gets a mostly empty page and JavaScript builds everything after it loads. SSR tends to feel faster on first load and is better for search engines, while CSR can feel smoother once the app is running. Most modern sites use a mix of both.”
Code Example
// Server-side rendering (runs per request, on the server)
async function renderPage(req) {
const data = await fetchFromDatabase(req.params.id)
return renderToHtmlString(PageComponent, { data }) // full HTML returned
}
// Client-side rendering (runs in the browser after page load)
async function mountApp() {
const root = document.getElementById("root") // starts empty
const data = await fetch("/api/item").then((r) => r.json())
renderIntoDom(root, PageComponent, { data }) // DOM built in-browser
}Follow-up Questions
- What is hydration and why can it be expensive?
- How does static site generation differ from SSR and CSR?
- When would you choose CSR over SSR for a dashboard app?
- What is streaming SSR and how does it improve time-to-first-byte?
MCQ Practice
1. In SSR, where is the initial HTML for a page generated?
SSR renders HTML on the server for each request, before sending it to the browser.
2. What does "hydration" mean in the SSR context?
Hydration attaches interactivity to server-rendered markup without re-rendering it from scratch.
3. Which is a typical downside of pure client-side rendering?
CSR ships a near-empty shell, so users see content only after the JS bundle downloads and runs.
Flash Cards
What does SSR return on first request? — A fully rendered HTML page built on the server.
What does CSR return on first request? — A minimal HTML shell plus JavaScript that builds the page client-side.
What is hydration? — Attaching event listeners/state to server-rendered HTML so it becomes interactive.
Which favors SEO by default: SSR or CSR? — SSR, since content is present in the initial HTML response.