How to Choose Between SPA and SSR for Business
SPA vs SSR is not a framework debate—it changes SEO, time-to-interactive, hosting cost, and operator UX. A decision frame for founders and PMs.
Ali Mortazavi
Founder, Paradise Code
Ask the right question: who gets the first HTML?
Classic SPAs build content in the browser after JS downloads. SSR/hybrid prepares meaningful HTML on the server so users and crawlers see substance sooner. For a corporate services page, that gap hits LCP and indexing; for a post-login admin tool, less so.
The common mistake is declaring the whole product “must be SSR” or “must be SPA.” Real products are mixed: marketing SSR, authenticated app client-heavy, some routes ISR/SSG.
A non-technical decision matrix
If organic traffic and link previews matter → lean SSR/SSG. If the product is a post-login tool with zero SEO value → SPA or client-rendered app routes can be simpler and cheaper.
If marketing ships landing pages weekly and needs reliable previews → hybrid with prerendered public routes. If operators work on weak networks → light initial HTML + selective hydration beats heavy SPA chrome.
Infrastructure cost and team complexity
Static SPAs are cheap on a CDN, but they do not remove API/auth complexity—they only move rendering. SSR needs Node or an edge runtime and introduces cache invalidation as a product concern.
Hidden SSR cost: no cache means every visit re-renders. Hidden SPA cost: long interaction delay on mobile networks and fat bundles. Measure a key journey on 4G, not office Wi-Fi.
Common business scenarios
Corporate site + blog: SSG/SSR. Catalog ecommerce with heavy filters: SSR or hybrid with fragment caching. Internal dashboard: SPA or client segments inside Next. SaaS: SSR marketing, client `/app`.
Migrating from slow WordPress to Next? Default public pages to server/static and keep the panel separate or in a client route group—do not rebuild the whole store as pure CSR.
Signals your current choice is wrong
Marketing LCP above ~2.8s on mobile, empty link previews in Telegram/LinkedIn, or key pages unindexed after weeks usually point to weak rendering strategy.
Conversely, if an internal panel is fully SSR’d and every filter click round-trips the server with full blinks, you over-servered. Internal tools should feel like apps, not full refreshes.
Practical recommendation
Start with a route map: public / private / semi-public. Assign a render strategy per group and lock it in a short ADR so the SPA/SSR holy war does not restart in three months.
Paradise Code teams typically ship a hybrid App Router: prerendered marketing, authenticated server data where sensitive, and interactive islands only where needed—so SEO and app feel both survive.
Frequently asked questions
Does Next.js mean we must use SSR?
No. Next can be static, server, client, or mixed. Choose per route, not per framework.
Is SPA enough for a small store?
Usually not for indexable catalog pages. At least prerender or SSR product and category pages.
Is SSR always faster?
No. Uncached SSR can be slower and costlier. Speed means useful HTML early + less JS + correct caching.
Which metric should decide?
Mobile LCP/INP on money pages, time-to-meaningful-content, and index/social-preview reliability.
Insights
Need these ideas implemented in your product?
Paradise Code supports you from consult to full delivery.