The verdict
Use static generation (SSG) for content that's the same for every user and changes infrequently — it's the fastest and cheapest, with excellent SEO. Use server-side rendering (SSR) when pages are personalized or must always reflect fresh data and you still need SEO and a fast first paint. Use client-side rendering (CSR) for highly interactive, behind-login app shells where SEO doesn't matter. Modern frameworks mix these per route (plus incremental regeneration and streaming), so decide per page, not per app.
How to decide
- 1Is the content identical for all users and rarely changing? → SSG (with ISR for periodic updates).
- 2Do you need SEO or a fast first paint? → SSR or SSG, not CSR.
- 3Is it personalized or must it always be fresh? → SSR.
- 4Is it behind login, app-like, and SEO-irrelevant? → CSR.
- 5Decide per route and combine — a static marketing page, an SSR product page, a CSR dashboard.
The options
SSG (Static Site Generation)
Pages pre-rendered to HTML at build time, served from a CDN.
Best for
- Marketing pages, docs, blogs
- Content identical for all users
- Anything that changes rarely
Strengths
- Fastest first paint; cheap CDN delivery
- Excellent SEO — full HTML with no server per request
- Scales trivially
Weaknesses
- Content is a build-time snapshot (mitigated by ISR)
- Not suitable for per-user/personalized pages
SSR (Server-Side Rendering)
HTML rendered on the server per request.
Best for
- Personalized pages that still need SEO
- Always-fresh data (dashboards, listings)
- Fast first paint on dynamic content
Strengths
- SEO + fast first paint for dynamic/personalized content
- Always reflects current data
Weaknesses
- Server cost and latency per request
- Hydration cost on the client
- Needs caching to scale
CSR (Client-Side Rendering)
A shell loads, then JavaScript fetches and renders in the browser.
Best for
- Behind-login app dashboards
- Highly interactive SPAs
- When SEO is irrelevant
Strengths
- Rich interactivity after load
- Cheap servers — mostly static assets + APIs
Weaknesses
- Poor SEO and slow first paint (blank until JS runs)
- Large JS bundles hurt low-end devices
Trade-offs at a glance
| Dimension | SSG (Static Site Generation) | SSR (Server-Side Rendering) | CSR (Client-Side Rendering) |
|---|---|---|---|
| First paint | Fastest | Fast | Slow (blank first) |
| SEO | Excellent | Good | Poor |
| Server cost | Lowest (CDN) | Higher (per request) | Low |
| Freshness | Build-time (ISR) | Per request | Client fetch |
| Personalization | No | Yes | Yes |
| Interactivity | After hydration | After hydration | Rich |
| Best for | Docs / marketing | Dynamic + SEO | App shells |
In the interview
In a frontend or full-stack system-design round, or as 'how would you render this page?' The interviewer wants a per-route decision tied to SEO, freshness, personalization, and cost.
What a Staff answer includes
A Staff answer decides per route rather than per app, ties each choice to SEO, freshness, personalization, and server cost, and is fluent in the trade-offs of hydration, streaming, and incremental regeneration.
Follow-ups you should expect
- →How would you render a personalized dashboard that also needs SEO for a public profile?
- →What's the cost of hydration, and how do you reduce it?
- →When would you use incremental static regeneration (ISR)?
- →How do you keep an SSR page fast under load?
Common mistakes
- ✕CSR for SEO-critical pages (search and social crawlers see a blank shell).
- ✕SSR everywhere, paying server cost/latency where SSG would do.
- ✕Ignoring hydration cost and shipping huge JS bundles.
- ✕Treating rendering as one app-wide choice instead of per route.
Further reading
Related decisions
REST vs gRPC vs GraphQL
REST for public, cacheable, resource APIs; gRPC for fast internal service-to-service calls; GraphQL when varied clients need to shape their own queries.
Monolith vs Microservices
Start with a modular monolith. Move to microservices only for a concrete driver — independent scaling, team autonomy, or fault isolation — and only with the ops maturity to run a distributed system.