Why rendering choice matters
In 2026, choosing between SSR, SPA, and SSG is no longer an abstract technical decision — it directly affects SEO, conversions, and hosting costs. A business site built as a pure SPA (e.g. React without SSR) loses 40-60% of organic traffic compared to the same application delivered via SSR or SSG.
In this article I'll show you the real differences with measured Core Web Vitals scores, and give you concrete recommendations based on project type.
Quick definitions (no buzzwords)
SPA — Single-Page Application
The browser receives an almost empty HTML and a large JavaScript bundle. JS builds the UI dynamically after load. Examples: create-react-app, Vue CLI, standalone Angular.
SSR — Server-Side Rendering
The server generates complete HTML on each request and sends it to the browser. JS then "hydrates" the page for interactivity. Examples: Next.js (app router), Nuxt, Laravel with Blade, Remix.
SSG — Static Site Generation
Pages are pre-generated at build-time as static HTML files and served directly from CDN. Examples: Astro, Hugo, Jekyll, Next.js static export, Gatsby.
Core Web Vitals comparison (real data)
I ran a test with the same page (blog post with ~1500 words, 3 images, 2 code blocks) implemented in each architecture. Device: Moto G Power (simulated in Lighthouse), 4G connection.
LCP (Largest Contentful Paint)
- SPA (pure React): 3.8s — hero image loads only after JS executes
- SSR (Next.js): 1.4s — HTML arrives with hero image already referenced
- SSG (Astro): 0.9s — CDN edge, minimal JS
INP (Interaction to Next Paint)
- SPA: 320ms — large bundle blocks the thread
- SSR: 180ms — hydration has cost, but less
- SSG: 80ms — minimal or no JS
TTFB (Time to First Byte)
- SPA: 200ms — index.html is small and fast
- SSR: 400-800ms — server renders on each request
- SSG: 50-150ms — served from CDN edge
Verdict: SSG wins on pure performance, SSR is close, SPA loses significantly.
When to choose SPA
SPA only makes sense when:
- The app is behind a login (SEO doesn't matter)
- Users interact heavily after load (dashboards, editors, CRMs)
- You need complex state and client-side routing
- The backend is a pure API, decoupled from frontend
Good fits: admin panels, SaaS dashboards, tools (Figma, Notion), internal apps.
Don't pick SPA for: marketing sites, blogs, e-commerce, portfolios, landing pages. You lose SEO and speed.
When to choose SSR
SSR is ideal for:
- Sites with dynamic content (user-specific, logged in or not)
- E-commerce with large catalogs and real-time stock
- Platforms with user-generated content
- Apps that need SEO and interactivity
Good fits: stores (Shopify, WooCommerce), social platforms, blogs with live comments, public dashboards.
Recommended 2026 stacks:
- Laravel + Blade + Livewire/Alpine — for PHP teams, stability, rich ecosystem
- Next.js 15 (App Router) — for React teams, best DX
- Remix / React Router 7 — for correct web fundamentals
- Rails 8 with Hotwire — modern Ruby alternative
When to choose SSG
SSG is the obvious choice for:
- Blogs and editorial sites
- Technical documentation
- Landing pages and marketing sites
- Personal portfolios
- Company presentation sites
Good fits: Astro (blogs, docs), Hugo (fast static sites), Eleventy (maximum flexibility), Next.js static export.
Main limitation: content only updates on rebuild. If you have thousands of pages changing frequently, rebuilds become slow.
The hybrid approach (winning in 2026)
The best 2026 projects combine all three. A modern e-commerce site might use:
- SSG for static pages (home, about, main categories)
- SSR for product pages (live pricing, stock)
- SPA only in cart and checkout (intensive interactivity)
Astro, Next.js 15, and Laravel with Inertia allow exactly this — you choose rendering per route, not per project.
Decision tree
Answer these questions in order:
- Is the content behind a login? Yes → SPA. No → continue.
- Does content change more often than you can rebuild (e.g. live stock, comments)? Yes → SSR. No → continue.
- Do you have under 1000 pages and rebuilds take under 2 minutes? Yes → SSG. No → SSR.
Common mistakes to avoid
1. "I use React everywhere, so I'm making an SPA"
React doesn't mean SPA. You can use React server-rendered (Next.js, Remix) without having an SPA. Pure SPA is an architecture decision, not a framework limitation.
2. "SSG is bad for SEO because content isn't fresh"
False. Google indexes static pages ideally. You can auto-rebuild (cron, webhook) when content changes. Vercel and Netlify do this in 30-60 seconds.
3. "SSR is expensive"
Partially true. But with proper caching (full-page cache in Redis or CDN), cost drops dramatically. Laravel with route cache + Cloudflare edge cache reaches ~90% hit rate.
My recommendation for 2026
For most business projects, the optimal stack is:
- Editorial sites / portfolios / marketing: Astro or Hugo (SSG)
- E-commerce / platforms with dynamic content: Laravel + Blade + Alpine (SSR, low cost) or Next.js 15
- SaaS / dashboards / tools: SPA (React + Vite, TanStack Router) or Next.js with app router
For anonym93.dev I used exactly this combination: Laravel 12 + Blade + Alpine.js for public pages (SSR with aggressive caching) and Filament for admin (React Livewire hybrid).
Conclusion
There is no "better" architecture in absolute terms. There's one that fits your use case. When in doubt, start with SSR (Laravel, Next.js) — it's the reasonable compromise between SEO, performance, and flexibility.
For a production-ready Laravel 12 setup, see Complete Guide: Laravel 12 + Vite + Tailwind v4.
For how to migrate an existing SPA to SSR, read Case Study: From React SPA to Blade + Alpine.js.