The Four Rendering Strategies
| Strategy | When HTML is generated | First load speed | SEO | Server load |
|---|---|---|---|---|
| CSR | In browser (runtime) | Slow | Poor | Low (static files) |
| SSR | On server (per request) | Fast | Excellent | High (per request) |
| SSG | At build time | Fastest | Excellent | Minimal (static files) |
| ISR | Build + periodic rebuild | Fastest | Excellent | Low (occasional rebuild) |
CSR — Client-Side Rendering
In CSR (the traditional React SPA approach), the server sends a minimal HTML file containing just a <div id="root"></div> and a large JavaScript bundle. The browser downloads the JS, executes it, and React renders the UI.
Pros: Rich interactivity, fast subsequent navigation (SPA), server just serves static files (cheap hosting), great for authenticated/personalised dashboards.
Cons: Slow initial load (must download + execute JS before anything shows), poor SEO (crawlers see empty HTML), poor performance on low-end devices.
SSR — Server-Side Rendering
With SSR, the server renders the full HTML page on each incoming request. The client receives fully populated HTML — visible immediately — and then JavaScript "hydrates" it to make it interactive.
Pros: Fast first contentful paint, excellent SEO, works without JavaScript (progressive enhancement), fresh data on every request.
Cons: Server must process every request (higher infrastructure cost), cannot serve from CDN edge (traditionally), Time To Interactive can be slow if JS bundle is large (hydration cost).
SSG — Static Site Generation
SSG pre-builds all HTML pages at deploy time. Pages are plain HTML files stored on a CDN. No server-side computation occurs at request time — the CDN just serves the file. This is the fastest possible delivery.
Pros: Fastest possible delivery, infinitely cacheable on CDN, lowest server costs (often free), excellent SEO.
Cons: Build time grows with number of pages (10,000 pages = long build), content staleness (rebuild required to update), not suitable for personalised or user-specific content.
ISR — Incremental Static Regeneration
ISR (a Next.js innovation) combines SSG performance with the ability to update content without full rebuilds. Each page has a revalidate time — it serves statically until that period expires, then regenerates in the background.
How ISR works: The page is built statically and served instantly. After 60 seconds, the next visitor triggers a background rebuild while still receiving the current (stale) page. Subsequent visitors get the fresh page. No user ever waits for a build.
Hydration — The Bridge Between SSR/SSG and Interactivity
When SSR or SSG pre-renders HTML, the user sees content immediately. But the page is not yet interactive — buttons do nothing, forms do not submit. Hydration is the process of React "taking over" the pre-rendered HTML by attaching event listeners and making it reactive.
Hydration Mismatch Errors
If the HTML rendered on the server differs from what React renders on the client, you get a "hydration mismatch" error. Common causes: using Math.random() or Date.now() in render, browser-only APIs (localStorage, window) accessed during render, different data on server and client. Always ensure server and client render the same initial output.
Next.js — Mixing Strategies Per Page
Next.js lets different pages in the same application use different rendering strategies. This is the key advantage of meta-frameworks:
React Server Components — Blurring the Line
React Server Components (RSC), default in Next.js App Router, run only on the server. They can access databases directly without an API layer, have zero JavaScript bundle cost (they don't ship JS to the browser), and compose with Client Components for interactivity. RSC effectively makes every component able to be server-side rendered, blurring the CSR/SSR distinction at the component level.
How We Research and Update This Guide
We test the underlying formula or workflow, compare outputs with reliable references, and revise examples whenever the page content changes.
- The workflow or formula is tested directly in the tool and compared against independent reference examples.
- Examples are kept practical so readers can verify the result without hidden assumptions.
- Pages are revised whenever the interface, calculation flow, or surrounding guidance materially changes.
Frequently Asked Questions — CSR vs SSR vs SSG
CSR (Client-Side Rendering): server sends a minimal HTML shell + JavaScript bundle. Browser downloads JS, runs it, and renders content. First paint is slow; subsequent navigations are fast. SSR (Server-Side Rendering): server renders full HTML on each request and sends it to the browser. Fast first paint, good SEO, but server work on every request. SSG (Static Site Generation): HTML is pre-built at deploy time. Server just serves static files — fastest possible delivery, perfect for content that rarely changes.
SSG has the best SEO — search engine crawlers receive fully rendered HTML immediately. SSR is also excellent for SEO — crawlers get rendered content on every request. CSR has historically been problematic for SEO — Google's crawler can execute JavaScript but may not wait for dynamic content, especially for complex SPAs. For SEO-critical content (blog posts, product pages, marketing pages), use SSG or SSR. For user-authenticated dashboards where SEO is irrelevant, CSR is fine.
ISR is Next.js's hybrid approach — pages are statically generated at build time, but can be regenerated in the background after a specified time (revalidate period). A page with revalidate: 60 is served statically for 60 seconds. After 60 seconds, the next request triggers a background rebuild — the stale page is served while the new one builds. This gives SSG's performance with the ability to update content without a full redeploy.
Use SSG when content does not change per user or changes infrequently — marketing pages, blogs, documentation, landing pages. Use SSR when content must be fresh on every request — dashboards, personalised pages, search results, pages that depend on cookies/auth. Use CSR for fully authenticated, private dashboards where SEO does not matter and real-time interactivity is the priority.
Hydration is the process of taking SSR or SSG-rendered HTML (which is already displayed to the user) and attaching JavaScript event handlers to make it interactive. The HTML is visible immediately (good for perceived performance and SEO) but the page is not interactive until hydration completes. Partial hydration and resumability (Qwik) are techniques to hydrate only the interactive parts, reducing the JavaScript execution cost.
A hybrid approach: Product listing pages and individual product pages → SSG with ISR (fast delivery, refreshes every few minutes to reflect price/stock changes). Search results → SSR (personalised, query-dependent). Shopping cart and checkout → CSR (authenticated, real-time). Next.js supports all of these in the same application — different pages use different strategies. The App Router in Next.js 14+ makes React Server Components the default, blending SSR and CSR at the component level.