Skip to content
Codeloom
Web

SPA vs SSR vs SSG: Rendering Strategies Explained

Understand Single Page Apps, Server-Side Rendering, and Static Site Generation — how each works, performance tradeoffs, SEO impact, and when to use which.

·6 min read · By Codeloom
Beginner 10 min read

What you'll learn

  • ✓How SPAs, SSR, and SSG render pages differently
  • ✓Performance and SEO implications of each approach
  • ✓When to use each rendering strategy
  • ✓How ISR and streaming fit into the picture
  • ✓Mixing strategies in modern frameworks

Prerequisites

  • •Basic HTML and JavaScript understanding

Every web page reaches the browser as HTML. The question is when and where that HTML gets generated. The answer determines your site’s performance, SEO, and architecture.

Single Page Application (SPA)

An SPA sends a minimal HTML shell and a large JavaScript bundle to the browser. JavaScript renders everything client-side.

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

The browser downloads app.js, executes it, fetches data from APIs, and renders the UI. Subsequent navigation happens entirely in the browser — no full page reloads.

How it works

  1. Browser requests the page
  2. Server returns empty HTML shell + JavaScript bundle
  3. Browser downloads and executes JavaScript
  4. JavaScript makes API calls and renders content
  5. User sees the page

Pros

  • Smooth, app-like navigation after initial load
  • Clear separation between frontend and backend
  • Works well for highly interactive applications
  • Simple deployment — just static files behind a CDN

Cons

  • Slow initial load — nothing renders until JavaScript executes
  • Poor SEO — search engines may not execute JavaScript
  • Blank screen while JavaScript loads (poor perceived performance)
  • Requires JavaScript — no progressive enhancement

Server-Side Rendering (SSR)

SSR generates the full HTML on the server for every request. The browser receives a complete page immediately.

User Request → Server renders HTML → Browser displays page → JavaScript hydrates

How it works

  1. Browser requests the page
  2. Server fetches data and renders HTML
  3. Browser receives and displays complete HTML
  4. JavaScript bundle loads and “hydrates” the page (attaching event handlers)
  5. Page becomes interactive

Pros

  • Fast First Contentful Paint — the browser has real HTML immediately
  • SEO-friendly — crawlers see complete content without executing JavaScript
  • Dynamic content — HTML is generated per-request with fresh data
  • Works without JavaScript (content is visible even if JS fails)

Cons

  • Slower Time to First Byte — the server must render before responding
  • Server load — every request requires rendering work
  • Hydration cost — JavaScript still loads and attaches to the server-rendered HTML
  • More complex infrastructure than static files

Static Site Generation (SSG)

SSG generates all HTML at build time. Pages are pre-built and served as static files from a CDN.

Build time: Fetch data → Generate HTML files → Deploy to CDN
Request time: CDN serves pre-built HTML → Browser displays instantly

How it works

  1. At build time, the framework generates an HTML file for every page
  2. HTML files are deployed to a CDN
  3. When a user requests a page, the CDN serves the pre-built file
  4. No server-side rendering happens at request time

Pros

  • Fastest possible response — CDN serves a static file
  • No server required — just static file hosting
  • Highly cacheable — the same file serves every user
  • Maximum SEO — complete HTML available instantly
  • Cheap to host and scale

Cons

  • Build time grows with page count — thousands of pages take minutes
  • Content is stale until the next build
  • Not suitable for per-user or real-time content
  • Rebuild required for any content change

Incremental Static Regeneration (ISR)

ISR bridges SSG and SSR. Pages are statically generated but can be re-generated in the background after a time interval:

First request: Serve cached static page
Background: Re-generate the page with fresh data
Next request: Serve the updated page

ISR gives you the performance of static pages with near-real-time content freshness. Next.js popularized this pattern.

Streaming SSR

Traditional SSR waits for all data before sending any HTML. Streaming SSR sends HTML in chunks as data becomes available:

Server starts sending <html><head>... immediately
Shell renders while data loads
Data arrives → server streams the content chunk
Browser progressively displays content

This dramatically improves Time to First Byte because the browser starts rendering before the server finishes processing.

Comparison Table

FactorSPASSRSSG
First Contentful PaintSlowFastFastest
Time to InteractiveSlowMediumFast
SEOPoorExcellentExcellent
Content freshnessReal-timeReal-timeBuild-time
Server requiredNo (API only)YesNo
Hosting costLowMedium-HighLowest
Build timeFastN/AGrows with pages
PersonalizationEasyEasyHard

When to Use SPA

  • Internal tools and dashboards behind authentication
  • Highly interactive applications (design tools, IDEs, email clients)
  • When SEO does not matter
  • When you want a clear frontend/backend API boundary

When to Use SSR

  • E-commerce with dynamic pricing and inventory
  • Social media feeds with personalized content
  • Any page that needs SEO and real-time data
  • Content that changes frequently and varies per user

When to Use SSG

  • Blogs, documentation, and marketing sites
  • Content that changes infrequently (daily or weekly)
  • Landing pages and portfolio sites
  • Any site where build-time content is acceptable

Mixing Strategies

Modern frameworks let you mix strategies per page. In Next.js, your marketing pages can be SSG, your product pages can use ISR, and your dashboard can be SSR or client-rendered. This is the practical reality — few applications use just one strategy.

/                    → SSG (marketing page)
/blog/*              → SSG (content pages)
/products/*          → ISR (refreshed every hour)
/dashboard           → SSR (per-user data)
/settings            → SPA (client-side only)

Wrapping Up

SPA, SSR, and SSG are not competing philosophies — they are tools for different problems. Use SSG for content, SSR for dynamic pages that need SEO, and SPA patterns for interactive features. Modern meta-frameworks let you mix all three in one application, so choose per-page based on the content and user experience requirements.

Related articles