InterviewLane
Back to Performance
Performance
medium
mid

What is client side rendering and when is it the right choice?

CSR: server ships a near-empty HTML + JS bundle; browser fetches data and renders. Pros: rich interactivity, cheap hosting (static), great for app-shell UIs after first paint. Cons: slow first paint, SEO challenges, bigger JS, blank-screen risk on slow networks. Right for authenticated app dashboards; wrong for content/SEO pages.

3 min read·~6 min to think through
Sign in to bookmark & track progress

Client-side rendering means the server returns minimal HTML and a JS bundle; the browser fetches data, builds the DOM, and renders.

How it works

ts
Server → HTML shell + bundle.js
Browser → execute bundle → fetch /api/data → render

First meaningful paint depends on bundle download + parse + data fetch — easily 1–3s on average networks.

When CSR is right

ContextWhy CSR
Authenticated dashboardSEO doesn't matter; rich interactivity dominates.
Internal toolsBehind login; perf budget loose.
Highly interactive UIs (editors, design tools)After first paint, subsequent navigation is instant.
Static host budgetCheap (S3/CDN); no server runtime.

When CSR is wrong

  • SEO-critical content — search engines render JS but slowly and inconsistently.
  • First-impression marketing pages — LCP suffers; conversion drops.
  • Mobile / weak networks — bundle download is the bottleneck.
  • Social previews — Open Graph crawlers don't execute JS.

Mitigations

  • Skeleton screens during fetch.
  • Code splitting so first paint loads minimum.
  • Prefetching for likely-next routes.
  • Service worker caching the shell.
  • Streamed data (Suspense + React Query).

CSR vs SSR vs SSG vs RSC

  • SSR: server renders HTML per request → fast first paint, hydration cost, server runtime needed.
  • SSG: HTML built at deploy time → fastest, but stale until rebuild.
  • RSC: server renders some components, ship less JS.
  • CSR: bundle does everything.

Modern apps mix: SSG/SSR for marketing + content, CSR after login.

Interview framing

"CSR ships an empty shell + JS; the browser does the rest. Right for authenticated app UIs where SEO doesn't matter and rich interactivity dominates — and where cheap static hosting is a plus. Wrong for first-impression content, SEO pages, mobile-weak networks. Mitigations: code splitting, skeletons, service worker caching, prefetching. Most real apps mix CSR for the authenticated app and SSR/SSG for public content."

Follow-up questions

  • •Why do search engines struggle with CSR?
  • •How does hydration relate to CSR?
  • •When have you chosen CSR over SSR?

Common mistakes

  • •Using CSR for SEO-critical marketing pages.
  • •Shipping a monolithic bundle on a content site.
  • •Assuming Googlebot runs your JS reliably.

Performance considerations

  • •Bundle size + parse + first fetch govern LCP. Code splitting + prefetch + caching are the levers.

Edge cases

  • •Social media link previews see the empty shell.
  • •Cold cache + weak network = blank screen for seconds.
  • •Hydration errors when CSR app reads server state.

Real-world examples

  • •Gmail, Notion, Figma, Linear — CSR-heavy after login. Marketing pages on the same product usually SSR/SSG.

Senior engineer discussion

Seniors choose rendering per route, not per app. They know CSR's failure modes (LCP, SEO, social previews) and the mitigations (RSC, streaming SSR, edge SSR).

Related questions