Server-Side Rendering (SSR) vs. Static Site Generation (SSG)

Client-side rendering (CSR), server-side rendering (SSR), and static site generation (SSG) each have different performance characteristics. Choosing the right approach for each page can dramatically impact your Core Web Vitals.

The Three Approaches

Client-Side Rendering (CSR)

The server sends a minimal HTML shell. JavaScript downloads, executes, and renders content in the browser.

<!-- What the server sends -->
<div id="root"></div>
<script src="/app.js"></script>

<!-- JavaScript renders everything -->

Server-Side Rendering (SSR)

The server renders the full HTML for each request. The browser receives ready-to-display content.

<!-- What the server sends (fully rendered) -->
<div id="root">
  <header>...</header>
  <main>
    <h1>Welcome</h1>
    <p>Content is already here</p>
  </main>
</div>
<script src="/app.js"></script> <!-- Hydrates for interactivity -->

Static Site Generation (SSG)

Pages are pre-built at build time. The server sends pre-rendered HTML files from cache.

<!-- Pre-built HTML file, served from CDN -->
<header>...</header>
<main>
  <h1>Welcome</h1>
  <p>Content was rendered at build time</p>
</main>

Performance Comparison

Metric	CSR	SSR	SSG
TTFB	Fast (tiny HTML)	Moderate (rendering time)	Fastest (cached HTML)
FCP	Slow (wait for JS)	Fast (HTML has content)	Fastest (pre-rendered)
LCP	Slow (JS must render)	Fast (content in HTML)	Fastest (content ready)
TTI	Slow (heavy JS)	Moderate (hydration)	Fast (less JS needed)
TBT	High (JS execution)	Moderate (hydration)	Low (minimal JS)

When to Use SSG

SSG is ideal for content that doesn't change between requests:

• ✅ Marketing/landing pages
• ✅ Blog posts and documentation
• ✅ Product pages (updated periodically)
• ✅ FAQ and help center pages
• ✅ Portfolio/showcase pages

SSG in Next.js

// This page is pre-rendered at build time
export default function BlogPost({ post }) {
  return <article>{post.content}</article>;
}

export async function generateStaticParams() {
  const posts = getAllSlugs();
  return posts.map(slug => ({ slug }));
}

SSG Advantages

• Fastest possible TTFB — served from CDN cache
• Free scaling — static files handle any traffic
• Best SEO — content is immediately available
• Cheapest hosting — static file hosting is nearly free

SSG Limitations

• Content is only as fresh as the last build
• Build times grow with page count
• Can't personalize per user
• Dynamic data requires client-side fetching

When to Use SSR

SSR is ideal for content that must be fresh on every request:

• ✅ Search results pages
• ✅ Personalized dashboards
• ✅ Real-time pricing pages
• ✅ User-specific content
• ✅ Pages with authentication-dependent content

SSR in Next.js

// This page renders on every request
export default async function SearchResults({ searchParams }) {
  const results = await searchDatabase(searchParams.q);
  return <ResultsList results={results} />;
}

SSR Advantages

• Always fresh — every request gets current data
• Personalization — can customize per user
• SEO-friendly — content in initial HTML
• Secure — sensitive data stays on server

SSR Limitations

• Higher TTFB than SSG (server processing time)
• Server costs scale with traffic
• Server must be available (not just CDN)
• Hydration cost on client

The Hybrid Approach: ISR

Incremental Static Regeneration combines SSG speed with SSR freshness:

// Page is static but regenerates every 60 seconds
export const revalidate = 60;

export default async function ProductPage({ params }) {
  const product = await getProduct(params.id);
  return <Product data={product} />;
}

ISR serves cached HTML instantly (like SSG) but regenerates pages in the background at configurable intervals.

The Hydration Problem

Both SSR and SSG with React require hydration — downloading and executing JavaScript to make the page interactive. This can delay INP:

Page Complexity	Hydration Time (Mobile)
Simple landing page	100-300ms
Blog post	200-500ms
E-commerce PDP	500-1000ms
Complex dashboard	1-3s

Solutions

• React Server Components — don't send JS for static portions
• Islands architecture — only hydrate interactive components
• Progressive hydration — hydrate visible components first
• Astro/Qwik — frameworks designed to minimize hydration

Decision Framework

Question	Yes → SSG	Yes → SSR
Same content for all users?	✅
Content changes less than hourly?	✅
Content is user-specific?		✅
Real-time data needed?		✅
SEO is critical?	✅ or SSR	✅
High traffic, low server budget?	✅

Monitor Your Rendering Performance

Whether you choose SSR, SSG, or a hybrid approach, monitoring ensures your strategy delivers the expected performance.

Track your performance →