SSR vs SSG vs CSR Tradeoffs

The Rendering Trilemma

Every page you ship makes a fundamental tradeoff: freshness vs speed vs interactivity. Pick wrong, and you get a fast page that shows stale data, a dynamic page that takes 3 seconds to load, or a perfectly fresh page that Google can't index.

Here's the thing most people miss: this isn't a one-time architectural decision. In a modern Next.js 15 app, you pick the rendering strategy per page or even per component. The question isn't "should my app use SSR or SSG?" It's "what does this specific page need?"

The Rendering Spectrum:

Build time ←————————————————————————→ Request time
   SSG          ISR          SSR          CSR

Fastest TTFB                        Freshest data
Best cacheability                   Most personalized
Stale until rebuild                 Slowest TTFB

The Mental Model

SSG: Static Site Generation

The HTML is generated once at build time. Every user gets the same pre-built file, typically served from a CDN edge node.

// Next.js 15 App Router: Static by default
// This page is SSG automatically — no special config needed
export default async function BlogPost({ params }) {
  const post = await getPost(params.slug)

  return (
    <article>
      <h1>{post.title}</h1>
      <div>{post.content}</div>
    </article>
  )
}

// Tell Next.js which pages to pre-generate
export async function generateStaticParams() {
  const posts = await getAllPosts()
  return posts.map(post => ({ slug: post.slug }))
}

What happens at build time:

1. Next.js calls generateStaticParams to get all slugs
2. For each slug, it renders the page to HTML
3. The HTML + RSC payload are saved as static files
4. At request time, the CDN serves the pre-built file — no server execution

Performance characteristics:

• TTFB: 10-50ms (CDN edge)
• LCP: Excellent (HTML arrives complete)
• Server cost: Near zero (static files)

When SSG wins:

• Content changes infrequently (docs, blog posts, marketing pages)
• Page content is the same for every user
• SEO matters and you want the fastest possible TTFB
• You have a known, finite set of pages

When SSG fails:

• User-specific content (dashboards, profiles)
• Real-time data (stock prices, live scores)
• Thousands of pages that change hourly (build time becomes a bottleneck)

SSR: Server-Side Rendering

The HTML is generated fresh on every request. The server fetches data, renders React components, and sends complete HTML to the browser.

// Next.js 15 App Router: Force dynamic rendering
export const dynamic = 'force-dynamic'

export default async function Dashboard({ params }) {
  const user = await getCurrentUser()
  const analytics = await getAnalytics(user.id)

  return (
    <div>
      <h1>Welcome, {user.name}</h1>
      <AnalyticsChart data={analytics} />
    </div>
  )
}

In the App Router, a page becomes SSR when it uses dynamic functions like cookies(), headers(), or searchParams, or when you explicitly set dynamic = 'force-dynamic'.

What happens per request:

1. User requests the page
2. The server executes the component (fetches data, renders React tree)
3. HTML is streamed to the browser (with streaming SSR)
4. Browser shows the HTML immediately, then hydrates for interactivity

Performance characteristics:

• TTFB: 100-500ms (depends on data fetching + server location)
• LCP: Good (HTML arrives with content, but slower than CDN)
• Server cost: Linear with traffic (every request = server work)

When SSR wins:

• Personalized content (user dashboards, feeds)
• Data that changes frequently and must be fresh per request
• SEO-critical pages with dynamic data
• Pages that depend on request context (cookies, auth, geolocation)

When SSR fails:

• Content that's the same for everyone (SSG is faster and cheaper)
• High-traffic pages where server cost scales linearly
• Pages where 1-second-old data is acceptable (ISR is more efficient)

CSR: Client-Side Rendering

The server sends a minimal HTML shell with a JavaScript bundle. The browser downloads, parses, and executes JS to render the page.

'use client'

import { useState, useEffect } from 'react'

export default function AdminPanel() {
  const [data, setData] = useState(null)

  useEffect(() => {
    fetch('/api/admin/stats')
      .then(res => res.json())
      .then(setData)
  }, [])

  if (!data) return <LoadingSkeleton />

  return <StatsGrid data={data} />
}

What happens:

1. Browser receives a near-empty HTML file
2. Downloads the JavaScript bundle (50-500KB+)
3. JS executes, React mounts, components render
4. Data fetches fire, components re-render with data
5. User finally sees content

Performance characteristics:

• TTFB: Very fast (tiny HTML shell)
• LCP: Poor (content only appears after JS download + execution + data fetch)
• FCP: Poor (blank screen until JS runs)
• SEO: Terrible (search engines see empty HTML)

When CSR is appropriate:

• Behind-auth dashboards where SEO doesn't matter
• Highly interactive apps (editors, IDEs, design tools)
• Real-time collaboration features
• When the page is essentially a desktop app in the browser

When CSR is wrong:

• Any page that needs SEO
• Content-heavy pages (articles, documentation, landing pages)
• Pages where first-load performance matters
• Mobile users on slow connections

The Decision Framework

Here's the actual decision tree you should walk through for every page:

Does the content change per user?
├── Yes → Does SEO matter?
│   ├── Yes → SSR (with streaming for slow data)
│   └── No → CSR is acceptable (but SSR still preferred)
└── No → How often does the content change?
    ├── Rarely (days/weeks) → SSG
    ├── Sometimes (minutes/hours) → ISR
    └── Constantly (seconds) → SSR with short cache

The Tradeoff Matrix

Strategy | TTFB   | Freshness | SEO | Server Cost | Personalization
---------|--------|-----------|-----|-------------|----------------
SSG      | Best   | Worst     | Best| Lowest      | None
ISR      | Great  | Good      | Best| Low         | None
SSR      | Good   | Best      | Good| Highest     | Full
CSR      | Fast*  | Best      | Bad | Low         | Full

* Fast TTFB but slow LCP (content appears late)

Production Scenario: The E-Commerce Platform

A team is building an e-commerce site with these page types:

1. Homepage — Same for everyone, updates when marketing pushes new campaigns
2. Product listing — Filters by category, shows inventory counts
3. Product detail — Shows reviews, pricing, availability
4. Cart — Fully personalized, real-time inventory checks
5. Checkout — User-specific, payment-sensitive

Here's the correct rendering strategy for each:

Homepage       → SSG + on-demand revalidation (marketing triggers rebuild)
Product listing → ISR (revalidate every 60s for inventory freshness)
Product detail  → ISR (revalidate every 60s) + client-side for real-time stock
Cart           → SSR (personalized, needs auth context)
Checkout       → SSR (security-sensitive, must be fresh, personalized)

The mistake teams make? Using SSR for everything because "we need fresh data." The homepage doesn't need SSR — it's the same for every user. Product pages don't need SSR — a 60-second-old inventory count is fine. Only the cart and checkout actually need request-time rendering.

Common Mistakes

Key Rules