Lesson 20 of 30

Rendering Strategies: SSR, SSG & CSR

Q: How would you decide between CSR, SSR, and SSG for a given page? Walk through a real app with multiple page types.

A strong answer covers: CSR: empty shell + client render, best for highly personalized/behind-login content where SEO doesn't matter; SSR: renders fresh HTML per request, best for content that changes per-request and needs to be crawlable; SSG: renders once at build time, best for rarely-changing content — cheapest/fastest to serve; strategies can be mixed per-route in one app.

Where and when HTML actually gets generated is a real architectural choice with three common answers, each trading off differently between build time, server load, and how fresh the content is.

14 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

A marketing blog's content rarely changes after publishing. Which rendering strategy fits best, and why?

CSR — client-side rendering is always the fastest option for any content typeSSR — server-rendering on every request guarantees the freshest contentSSG — content rarely changes, so a build-time render served statically is the cheapest and fastest fit

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Rendering Strategies: SSR, SSG & CSR

What interviewers actually ask about this, and what a strong answer has to cover.

How would you decide between CSR, SSR, and SSG for a given page? Walk through a real app with multiple page types.

A strong answer covers

CSR: empty shell + client render, best for highly personalized/behind-login content where SEO doesn't matter
SSR: renders fresh HTML per request, best for content that changes per-request and needs to be crawlable
SSG: renders once at build time, best for rarely-changing content — cheapest/fastest to serve; strategies can be mixed per-route in one app

Likely follow-ups

What specifically breaks for SEO with a pure CSR app?
What is ISR, and what gap does it fill between SSR and SSG?
Does SSR eliminate the need to ship client-side JavaScript?

Practice these with the AI interviewer →

The plain-language idea

CSR (Client-Side Rendering) — the server sends a nearly-empty HTML shell; the browser downloads JavaScript, which then fetches data and renders everything. Fast to build, but the user sees a blank page until JS finishes loading and running.
SSR (Server-Side Rendering) — the server runs the app's render logic on every request, sending fully-formed HTML immediately (then hydrates, from the React track's hydration lesson). Content is always fresh, but every request costs real server compute.
SSG (Static Site Generation) — the HTML is rendered once, at build time, and served as a plain static file from a CDN thereafter. Extremely fast and cheap to serve, but the content is only as fresh as the last build/deploy.

CSR, SSR, SSG: when and where the HTML gets builtStep 1 of 3

CSR: browser downloads a near-empty shell + JS, renders everything client-side — slow first paint, fast navigation after.

Picking one is about the content, not a framework preference

| | Content changes | Best fit | |---|---|---| | CSR | Highly personalized, behind login | Dashboards, admin panels | | SSR | Changes per-request, needs to be fresh + indexed | A logged-in feed, search results | | SSG | Rarely changes | Marketing pages, blog posts, docs |

What people usually miss

Watch out

SEO is the classic reason to avoid pure CSR — a search crawler that doesn't fully execute JavaScript (or executes it with reduced fidelity) sees an empty shell; SSR/SSG send real content in the initial HTML that any crawler can read immediately.
These aren't mutually exclusive within one app. A real app commonly mixes strategies per-route: SSG for the marketing pages, SSR for a personalized dashboard, CSR for a highly interactive in-app tool — the choice is per-page, not whole-app.
SSR doesn't eliminate client-side JavaScript. The page still hydrates (becomes interactive) client-side after the initial HTML — SSR changes what shows up first, not whether JS ships and runs at all.

Why this matters in interviews

"Would you use SSR or SSG for this page?" is a genuinely practical architecture question — matching the strategy to how often the content changes and who needs to read it (users vs. search crawlers) is a stronger answer than defaulting to whichever a specific framework makes easiest.