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

StrengthWeakness
Low server cost — serves static files onlySlow FCP — nothing visible until JS runs
Simple caching — shell and bundle are CDN-friendlyFull app ships to client; large bundles without code splitting
Fast navigations after initial loadSEO requires JS-capable crawlers