SSR vs SSG vs CSR: Rendering Architecture Tradeoffs

In the mid-2010s, the industry took a wrong turn. Drawn to the fluidity of single-page apps (SPAs) built with React and Angular, developers moved everything to client-side rendering (CSR) — from heavy SaaS dashboards to simple text blogs.

For content sites, the result was poor. Users on low-end Android phones over 3G stared at blank screens for several seconds while the device downloaded and parsed multiple megabytes of JavaScript. SEO suffered and Time-to-Interactive (TTI) got worse.

The lesson: rendering strategy isn’t one-size-fits-all. Meta-frameworks (Next.js, Astro, Nuxt) emerged to let you choose where the HTML is computed.

Choosing between SSR, SSG, and CSR is an infrastructure decision. It affects your server costs, CDN strategy, Core Web Vitals, and conversion rate.

This guide walks through how each strategy executes, what “hydration” is, and how to choose per route to hit top Lighthouse scores.

1. Architectural Execution Models

To understand the performance delta, you must understand the exact sequence of events that occurs when a user types a URL into their browser and hits Enter.

CSR: Client-Side Rendering (The SPA Model)

1. The Request: The browser requests https://app.com/dashboard.
2. The Blank Payload: The server instantly returns a microscopic index.html file containing a single <div id="root"></div> and a <script> tag pointing to bundle.js. The user sees a blank white screen.
3. The Download Penalty: The browser must establish new HTTP connections to download the large JavaScript bundle.
4. The V8 CPU Penalty: The browser parses the JS bundle into an Abstract Syntax Tree (AST), compiles it, and executes the React framework.
5. The API Waterfall: React boots up and realizes it needs user data. It makes a fetch() request back to the server. The user stares at a loading spinner.
6. The Paint: The data arrives, React constructs a large Virtual DOM, patches the real DOM, and the user finally sees the dashboard.

SSR: Server-Side Rendering

1. The Request: The browser requests https://app.com/dashboard.
2. The Server Bottleneck: A Node.js server receives the request. It holds the connection open while it makes database calls, fetches API data, and executes React’s renderToString() method to generate the full HTML structure in server memory.
3. The First Paint: The server sends the full HTML string to the browser. The browser paints it instantly. The user sees the full dashboard immediately. Excellent SEO.
4. The Uncanny Valley (Hydration): The page looks finished, but it is dead. Clicking a button does nothing. In the background, the browser downloads the React JavaScript bundle and executes it. React maps its Virtual DOM over the existing HTML and attaches event listeners. This CPU-heavy process is called Hydration.
5. Interactive: The hydration finishes, and the page is finally usable.

SSG: Static Site Generation

1. The Build Step (CI/CD): When the developer pushes code to GitHub, the CI/CD pipeline fetches all database data, executes React, and generates a folder of thousands of raw 1.html, 2.html files.
2. The Edge Distribution: Those static files are pushed to an Edge CDN (like Cloudflare or Vercel), physically copying them to servers in 300+ cities globally.
3. The Request: A user in Tokyo requests https://app.com/blog. The Cloudflare node in Tokyo instantly returns the raw HTML file.
4. The Paint: Because the file requires zero server computation and travels minimal physical distance, Time-to-First-Byte (TTFB) is often under 20ms. The page paints instantly.

2. Comprehensive Technical Comparison Matrix

3. Deep Dive: The Hydration Bottleneck

A common misconception is that SSR solves all performance problems. SSR doesn’t make your app faster; it changes the perception of speed.

When you server-render with Next.js or Nuxt, you process the app twice:

1. The server executes React to generate the HTML.
2. The browser executes that same React code again to hydrate the DOM.

If a page has 5,000 DOM nodes (a large product grid), hydration becomes a bottleneck. The user sees the grid instantly (thanks to SSR), but clicking “Add to Cart” does nothing for a second or two while the main thread is busy attaching event listeners to all 5,000 nodes. The user clicks repeatedly, causing race conditions.

The Architectural Mitigation: Islands Architecture

Frameworks like Astro solved the hydration nightmare by inventing Islands Architecture. Instead of sending a large React bundle to hydrate the entire page, Astro sends zero JavaScript by default. The HTML is entirely static. If the architect wants a specific component to be interactive (e.g., an Image Carousel), they explicitly define it as an “Island” (<Carousel client:load />). The browser only downloads and hydrates the 15KB of JavaScript required for that specific carousel, leaving the other 4,950 DOM nodes completely static. This completely eliminates the Uncanny Valley of hydration latency.

4. Edge-Case Engineering Scenarios & Architectural Workarounds

Scenario A: The Million-Page E-commerce Site

The Problem: Amazon has 500 million product pages. Prices change dynamically every 10 minutes.

• The SSG Failure: You cannot use SSG. Building 500 million static HTML pages during a CI/CD pipeline would take 3 months to compile. Furthermore, if a price changes, you would have to trigger a rebuild, rendering the architecture impossible.
• The CSR Failure: You cannot use pure CSR. If Googlebot sees a blank page, your 500 million products will never index, and your company will go bankrupt.
• The SSR/ISR Solution: The architecture must utilize SSR combined with aggressive Edge caching (stale-while-revalidate), or ISR (Incremental Static Regeneration). The system serves a cached HTML page to the user instantly. In the background, if the cache is older than 10 minutes, the Edge network quietly triggers a localized SSR render to update the price for the next visitor.

Scenario B: The High-Security Banking Dashboard

The Problem: A bank builds a dashboard displaying sensitive PII (Personally Identifiable Information) and checking balances.

• The SSG Failure: Completely invalid. You cannot pre-compile private user data into static HTML files and push them to a public CDN.
• The SSR Vulnerability: While possible, SSR introduces severe security risks. The server must manage the user’s authentication token, fetch the PII, inject it into the HTML, and send it over the wire. If the server caching layer is misconfigured, User A might accidentally be served User B’s cached HTML.
• The CSR Solution: Pure CSR is the absolute optimal choice. The server returns a generic, blank, heavily cached HTML shell. The user’s browser, utilizing a secure HttpOnly cookie, makes an authenticated REST API call directly to the backend. The PII is assembled entirely inside the safety of the user’s local browser sandbox. Because SEO is irrelevant for a private dashboard, CSR is flawless here.

Scenario C: The Heavy B2B Web Application (Figma/Notion)

The Problem: You are building a complex vector graphics editor that runs in the browser.

• The Architectural Reality: Rendering paradigms don’t apply to WebGL or Canvas-heavy applications. The entire concept of SSR relies on HTML DOM nodes. If your application is a large WebAssembly blob running inside a <canvas> element, you are building a native application that simply uses the browser as a host. You must use CSR, aggressively utilizing Service Workers and IndexedDB to cache the WebAssembly binaries locally.

5. The Future: Streaming SSR and React Server Components (RSC)

The bleeding edge of architectural design is currently attempting to merge the benefits of SSR and CSR natively.

React Server Components (RSC) are a major shift. Historically, a component always shipped its JavaScript to the browser. With RSC, a developer can explicitly define a component to only execute on the server. If you have a MarkdownParser component that requires a 2MB library, you execute it on the server. The server sends down only the resulting HTML string. The 2MB library is never sent to the user’s browser. This drastically reduces JavaScript bundle sizes while maintaining the developer ergonomics of component-based architecture.

Furthermore, Streaming SSR utilizing HTTP/2 allows the server to send the HTML shell instantly, and then “stream” in the heavy database-dependent chunks (like a comment section) over the same connection as they finish calculating. This bypasses the historic SSR bottleneck where the server had to wait for the absolute slowest API call to resolve before sending a single byte of HTML.

6. The Verdict

Using one rendering strategy for an entire site is a mistake. Modern apps are hybrid.

1. Use SSG for your marketing site, docs, and blog. A blog post shouldn’t need server computation — pre-build it, serve it from a CDN, and get top Lighthouse scores.
2. Use CSR for interactive, authenticated dashboards. Offload UI rendering to the user’s device, save on server costs, and keep PII behind REST API boundaries (SEO doesn’t matter for a private dashboard).
3. Use SSR / ISR for dynamic, public, SEO-critical pages — product catalogs, news feeds, pricing pages — while watching your hydration overhead.

Treat rendering as a per-route decision and you get a site that ranks well, loads fast on mobile, and scales.