SSR vs SSG vs SPA — Which Rendering Strategy for Your Project?
Three rendering strategies, each with trade-offs. Here’s how to pick the right one.
Quick definitions
SSG (Static Site Generation): Pages built at build time. Served as static HTML files. Fastest possible load times.
SSR (Server-Side Rendering): Pages built on each request. Server generates HTML, sends it to the browser. Fresh data on every load.
SPA (Single-Page Application): Browser downloads a JavaScript bundle, renders everything client-side. No page reloads after initial load.
The decision framework
Use SSG when:
- Content doesn’t change often (blog, docs, marketing site)
- SEO matters
- You want the fastest possible page loads
- You can rebuild when content changes
Examples: Blog, documentation, landing pages, portfolio, changelog
Tools: Astro, Next.js (static export), Hugo, Eleventy
Use SSR when:
- Content is personalized or changes frequently
- SEO matters AND data is dynamic
- You need fresh data on every page load
- You have user-specific content (dashboards, feeds)
Examples: E-commerce product pages, social media feeds, news sites, search results
Tools: Next.js, Nuxt, Remix, SvelteKit
Use SPA when:
- SEO doesn’t matter (internal tools, dashboards)
- The app feels like a desktop application
- Real-time updates are important
- Users stay on the page for long sessions
Examples: Admin dashboards, chat apps, design tools, email clients
Tools: React (Vite), Vue, Svelte, Angular
The hybrid approach (what most apps actually need)
Modern frameworks let you mix strategies per page:
/ → SSG (marketing page, rarely changes)
/blog → SSG (rebuild on new post)
/blog/:slug → SSG (each post is static)
/dashboard → SSR (personalized, needs auth)
/app → SPA (interactive, real-time)
/products/:id → SSR (inventory changes, SEO needed)Next.js, Nuxt, and SvelteKit all support this. You don’t have to pick one strategy for your entire app.
Performance comparison
| Metric | SSG | SSR | SPA |
|---|---|---|---|
| First load | ⚡ Fastest | 🟡 Medium | 🔴 Slowest |
| Navigation | 🟡 Full reload | 🟡 Full reload | ⚡ Instant |
| SEO | ⚡ Excellent | ⚡ Excellent | 🔴 Poor |
| Server cost | ⚡ Cheapest (CDN) | 🔴 Highest (compute) | ⚡ Cheap (CDN) |
| Data freshness | 🔴 Build time | ⚡ Real-time | ⚡ Real-time |
Common mistakes
Using SSR for a blog. Your blog posts don’t change between requests. SSG gives you faster loads and zero server costs.
Using SPA for a marketing site. Google can index SPAs, but it’s slower and less reliable. SSG or SSR is better for SEO.
Using SSG for a dashboard. Dashboards show personalized, real-time data. You can’t pre-build that at build time.
Over-using SSR. SSR means your server renders every page on every request. At scale, that’s expensive. Use SSR only for pages that genuinely need fresh data AND SEO.
The simple rule
- Can you build it at deploy time? → SSG
- Does it need fresh data AND SEO? → SSR
- Is it an interactive app behind a login? → SPA
When in doubt, start with SSG. It’s the simplest, fastest, and cheapest. Add SSR or client-side rendering for the pages that need it.
Related resources
Related: What is Next.js · React Interview Questions