When a SPA Makes Sense, and When It Costs You a Week

The SPA is the right answer when the user spends the session in the app — the dashboard, the editor, the trading platform, the design tool. The user arrives once, signs in, and the session is the product. SEO is irrelevant; deep links are second-order; the network is fast.

A SPA is also the right answer when the data is real-time and the UI is stateful — the chat, the trading platform, the multiplayer editor. The SPA's mental model (the client is the source of truth, the server is the data layer) fits the use case, and the alternatives (server-rendered with polling, server-sent events on every state change) are more expensive.

A SPA is the right answer when the team is strong in React, Vue or Svelte, and the build is a single deployable artefact. The team velocity is the strongest argument for a SPA, and the SEO cost is a non-issue.

The SPA is the wrong answer when the user arrives from a search engine. A SPA without server-side rendering is invisible to the search engine for the first paint, and the prerender is a workaround that adds complexity. The right answer for a search-led product is server-rendered HTML, with the JS for the interactive parts. Next.js, Nuxt, Remix and SvelteKit are the right default for that.

The SPA is the wrong answer when the product is a content site — a publication, a documentation site, a marketing site. The SPA's mental model is wrong for the use case, and the bundle tax is a real cost on mobile.

The SPA is the wrong answer when the team is not strong in the framework. A SPA is more complex than a server-rendered app, and a team that has not built one before will spend the first sprint on the framework, not the product. The right answer is the simpler rendering model, with a migration to a SPA when the team is ready.

A SPA without a clear reason is a week of debugging you do not need. A SPA with a clear reason is the right architecture and a week of work you can afford.

Most products do not need a full SPA. Most products need a server-rendered HTML page with islands of interactivity — the form, the modal, the chart, the cart. The right architecture is SSR with hydration, and the right framework is Next.js, Nuxt, Remix, SvelteKit, or Astro.

SSR with hydration gives you the SEO of server-rendered HTML, the bundle of a server-rendered app, and the interactivity of a SPA on the parts of the page that need it. The mental model is "the server renders, the client enhances". The trade-off is the hydration cost (the client rebuilds the DOM the server sent), but the cost is bounded and the architecture is well-known.

For the 80% of products that do not need a full SPA, SSR with hydration is the right answer. The remaining 20% is a SPA when the user lives in the app, and a static site when the user is just passing through.

A SPA without SSR is invisible to the search engine for the first paint. The workaround is prerendering (render the SPA at build time, serve the HTML, hydrate on the client), but the workaround has its own cost — the build is slower, the deploy is more complex, and the routes that depend on user state cannot be prerendered.

A SPA with SSR is the right answer for SEO, but the SSR is another deployable, another failure mode, another thing to monitor. The right answer for SEO is SSR + ISR (incremental static regeneration) or SSR + a CDN that caches the HTML. The architecture is well-known, and the cost is the engineering to keep it running.

Pick the rendering model against the user journey. If the user arrives from a search engine and the product is a content site, server-rendered HTML with islands of interactivity is the right answer. If the user signs in once and the session is the product, a SPA is the right answer. If the user does both, the right answer is a server-rendered shell with a SPA for the signed-in parts.

The framework will support whatever you choose. The brief is where the choice is made.

If you want a second opinion on the rendering model, our web application development team can run the review. If the brief is "we need a content site that ranks", our website development engagement is the right one.