Last updated: Apr 29, 2026
Client-Side Rendering
The server responds with a nearly empty HTML document — a <div id="root"> and a <script> tag. The browser downloads the JavaScript bundle, executes it, and constructs the DOM on the client. This is the default model for single-page applications built with React, Vue, or Angular using a vanilla setup (no SSR framework).
How It Works
┌──────────┐ ┌──────────┐
│ Server │ │ Browser │
└────┬─────┘ └────┬─────┘
│ bare HTML + <script> │
│────────────────────────→│
│ │ parse HTML (almost empty)
│ │ download JS bundle
│ │ execute JS, build DOM
│ API requests (data) │
│←────────────────────────│
│ JSON responses │
│────────────────────────→│
│ │ render UI with data
The browser receives a minimal page, downloads and runs JS, mounts the app, then fetches data from APIs. After the initial load, route changes happen entirely on the client via the History API — no server round-trip for HTML, so subsequent navigations are fast.
SEO
Googlebot and other JS-capable crawlers can index the content, but crawl budget is limited — JS execution is more expensive than reading static HTML, so indexing may be delayed. Not all crawlers run JavaScript, and social-media link previews rely on the initial HTML response. For content-heavy public pages, CSR alone is usually not enough.
Trade-offs
| Strength | Weakness |
|---|---|
| Low server cost — serves static files only | Slow FCP — nothing visible until JS runs |
| Simple caching — shell and bundle are CDN-friendly | Full app ships to client; large bundles without code splitting |
| Fast navigations after initial load | SEO requires JS-capable crawlers |