Photo by Florian Olivo on Unsplash
React SPA vs Next.js SSR for Ecommerce: When to Use Each
React SPA vs Next.js SSR for Ecommerce: When to Use Each
The React vs Next.js debate is usually framed as a technology question, but for ecommerce stores it's really a business question: does organic search drive your revenue?
That single question decides whether you should ship a single-page application (SPA) built with Vite, or a server-rendered Next.js storefront. Everything else — performance, deployment cost, developer velocity — is secondary.
This guide walks through when each approach wins, the trade-offs that actually matter, and how to pick without over-engineering.
TL;DR — the 30-second answer
| Your situation | Pick |
|---|---|
| Organic search is a major traffic source | Next.js SSR (browse Next.js templates) |
| You're behind auth (B2B, internal tool, dashboard) | React SPA can be appropriate, but request it as a custom port |
| You're replatforming a store that ranks today | Next.js SSR — don't lose rankings |
| You're building an MVP to validate demand | React SPA — ship faster, iterate more |
| You need static hosting (no Node server) | React SPA |
| You want Incremental Static Regeneration (ISR) | Next.js — the SPA equivalent doesn't exist |
When in doubt, default to Next.js SSR for customer-facing storefronts and React SPA for everything else.
What each one actually does
React SPA (Vite). You build a bundle of JavaScript and static assets. The browser downloads index.html (nearly empty), then React takes over, fetches product data, and renders the page entirely in the browser. Every page transition is client-side — no round trip to a server.
Next.js SSR. You build a Next.js app. On every request (or at build time / revalidation time for SSG/ISR), the server runs your React components, fetches data, and returns fully rendered HTML. The browser gets a complete page immediately, then React hydrates it for interactivity.
The consequence:
- A React SPA shows empty HTML, then populated content to search crawlers
- A Next.js SSR page shows fully populated HTML to search crawlers
Google's crawler now executes JavaScript, but it does so in a second pass that can lag significantly. For pages where ranking matters — product pages, category pages, any content page — you don't want that lag.
The SEO gap (this is the whole argument)
If organic search drives revenue, Next.js SSR is non-negotiable. Here's why, concretely:
1. First-pass indexing. Next.js pages show up in Google's index fast because they ship complete HTML. SPAs wait for Google's render queue, which can take hours to days per page and is not guaranteed.
2. Meta tags and Open Graph. Social platforms (Twitter, Facebook, LinkedIn, Slack) don't execute JavaScript when they render link previews. They fetch the HTML once and read the <meta> tags. On an SPA, those tags are empty or static. On Next.js, they're personalized per page.
3. Structured data. Product JSON-LD needs to be in the initial HTML for Google to pick it up reliably. You can inject it client-side, but you're adding latency to the indexing pipeline for no reason.
4. Core Web Vitals. SSR + ISR pages typically beat SPA pages on LCP (Largest Contentful Paint) because the HTML arrives with the content already there. You don't have to wait for JS parse + API fetch + DOM update before the user sees anything. See our benchmarks page for real numbers.
5. Crawl efficiency. A Next.js site with SSR burns less of Google's crawl budget per page because each fetch returns a complete document. An SPA forces Google to execute JavaScript for every URL, which is expensive and rationed.
None of this means SPAs can't rank. They can, and many do. It means SPAs rank despite being SPAs, not because of them, and you're fighting the architecture the whole way.
When the SPA advantage actually matters
SPAs are not worse than Next.js. They're worse for ecommerce stores that need organic search. For everything else, the trade-off flips.
Internal tools and dashboards. Nobody is trying to rank an internal tool on Google. The SPA model — ship once, render forever — is simpler and perfectly adequate.
Authenticated-only experiences. If the only pages that matter are behind a login, SEO is irrelevant. Use the simpler deployment model.
B2B portals and quote tools. Same reason. The SEO pages (marketing landing pages) live on a separate marketing site; the actual app is an SPA.
Static hosting requirements. If your ops team insists on S3 + CloudFront, Cloudflare Pages, or another pure-static target, a Vite SPA builds to a handful of files that work on any of them. Next.js needs either Vercel, a Node server, or the output: 'export' static build — which gives up SSR anyway.
Rapid prototyping. Vite's dev server is ~2x faster than Next.js's on cold start and marginally faster on hot reload. For genuine prototyping (not launches), the velocity compounds.
The cost angle
Most people underestimate this: hosting costs differ by an order of magnitude between the two approaches.
React SPA on Cloudflare Pages or Vercel free tier: $0/month for most stores until you hit unusual traffic. The build produces static files; the CDN serves them. There's no server to pay for.
Next.js SSR on Vercel: Free tier works for tiny stores but you'll hit function invocation limits fast. A realistic mid-sized store runs $20-80/month for function execution on top of bandwidth.
Next.js ISR on Vercel: Better than SSR because cached pages don't count as function invocations. Still more expensive than a pure SPA, but the difference is small if you set revalidation windows correctly.
Self-hosted Next.js: ~$20-100/month for a server big enough to handle production traffic. Lower long-term than Vercel if your traffic grows, more ops overhead.
For a store doing $10k/month in revenue, the hosting cost delta is a rounding error. For a side project doing $100/month, it can be most of your infrastructure budget. Factor it in when you pick.
Performance in practice
A common misconception: "SPAs are faster because they skip server rendering."
That's true after the first page load. Client-side routing between pages in an SPA is near-instant. But the first load is slower than SSR because:
- The browser has to download the JavaScript bundle
- Parse it
- Execute it
- Fetch the product data from the API
- Render the page
Next.js SSR ships the rendered HTML immediately. The first paint happens before JavaScript even starts executing.
The real performance story is nuanced:
| Metric | SPA | Next.js SSR/ISR |
|---|---|---|
| First page LCP (cold) | Slower | Faster |
| Subsequent page transitions | Faster | Slightly slower (prefetch helps) |
| Cached repeat visit | Fast | Fast |
| Interactive state (cart, filters) | Fast | Fast after hydration |
For stores where users land on a product page from Google, bounce rate is high, and session depth is 1-2 pages (the typical ecommerce profile), the first-load advantage of SSR matters much more than the transition-speed advantage of SPAs.
For stores where users log in once and use the app for hours, the transition-speed of SPAs matters more.
Guess which profile applies to your store before picking.
The migration escape hatch
If you're torn, here's some good news: migrating from React SPA to Next.js is easier than it looks.
Your components, hooks, business logic, and API layer all port over with minimal changes. The hard parts are:
- Replacing React Router with the Next.js App Router
- Moving client-side data fetching to server components
- Setting up the Next.js deployment target
A focused team can migrate a small SPA to Next.js in 2-4 weeks.
The reverse migration (Next.js to SPA) is much rarer but also possible. You'd give up SSR, ISR, and server components — which is usually a downgrade, not an upgrade.
Practical advice: if you might need SEO later, start with Next.js now. If you definitely don't need SEO (auth'd app, internal tool), start with a SPA. Don't optimize for a migration you might not do.
How MVPHub handles storefront delivery
MVPHub now keeps the buying path deliberately simple: each ecommerce listing has one canonical Next.js storefront ready to buy. Alternative framework ports are scoped and purchased on demand.
- Next.js templates — production-grade SSR + ISR storefronts
- Request a framework port — tell us the target stack and delivery requirements
For customer-facing ecommerce, start from the production-ready Next.js version. Request another framework only when your deployment constraints or existing team architecture require it.
The one-line decision rule
If organic search drives revenue, pick Next.js. Otherwise, pick whatever ships faster.
Everything else — performance, cost, deployment — is downstream of that question. Answer it first, then let the tech follow.
Next steps
- Browse Next.js templates — production-grade SSR storefronts
- Request a framework port — on-demand alternatives
- See performance benchmarks — measured CWV data
- Read Best Next.js Ecommerce Templates in 2026 for the deeper architecture comparison
- Read Shopify Headless Template Guide if you're pairing with Shopify
The framework matters less than the architecture, and the architecture matters less than matching your revenue channel. Pick accordingly.
