SPA vs SSR vs Prerendering: Which One Should You Actually Use?

If you've been Googling JavaScript SEO for more than ten minutes, you've hit the SPA vs SSR debate. Everyone has strong opinions. Most are oversimplified. Here's a no-BS breakdown.

SPA (Single Page Application)

The default output of npm create vite@latest. Your entire app runs in the browser.

Pros: Fast after initial load, great DX, easy to deploy, perfect for dashboards and tools behind a login.

Cons: Terrible SEO out of the box. Crawlers see an empty page.

Best for: Internal tools, authenticated apps, SaaS dashboards.

SSR (Server-Side Rendering)

The server renders your app into HTML on every request. Frameworks: Next.js, Nuxt, SvelteKit, Remix.

Pros: Best SEO, fastest First Contentful Paint, works for all crawlers.

Cons: Requires a Node.js server, higher cost, more complex architecture.

Best for: E-commerce, content sites, marketing pages where SEO is critical from day one.

Prerendering

A middle path. Your app stays a SPA. A service detects crawler requests and returns fully rendered HTML. Real users get the SPA.

Pros: Zero code changes, works with any existing SPA, covers all crawlers including AI bots.

Cons: Not as fast as SSR for real users on first load, cached snapshots can be slightly stale.

Best for: Existing SPAs that need SEO without a full rewrite.

The decision matrix

• New project + SEO critical → Next.js (SSR/SSG)
• Existing SPA + need SEO now → Prerendering
• Dashboard behind login → SPA, no prerendering needed
• Blog or docs site → Static generation (Astro, Gatsby)