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

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

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."