SPA vs SSR: Choosing Between a Single-Page App, Server Rendering and the Next.js App Router

When should I choose a single-page application versus server-side rendering or the Next.js App Router?

Choose static generation or server-side rendering for public pages that need search visibility and a fast first load, and a single-page application pattern for authenticated, highly interactive screens where SEO does not matter. If your product has both, the Next.js App Router is a good fit because it renders Server Components by default and lets you mark only the interactive parts as Client Components. A pure SPA (for example, Vite and React with a separate API) is still a good choice for an app that lives entirely behind a login.

The terms, briefly

• Single-page application (SPA): the Next.js documentation defines a strict SPA as one served by a single HTML file, where every route, transition and data fetch is handled by JavaScript in the browser and there are no full-page reloads.
• Server-side rendering (SSR): HTML is generated on the server for each request, so the browser receives content before JavaScript runs.
• Static generation (SSG) or prerendering: HTML is generated at build time (or regenerated periodically) and served from a CDN.
• React Server Components: components that run only on the server. In the Next.js App Router, layouts and pages are Server Components by default, and you add "use client" to the files that need state, event handlers or browser APIs.

Decide by page type

SEO implications

Google can index JavaScript-rendered pages, but Google Search Central's JavaScript SEO basics guide explains that it processes them in three phases (crawling, rendering and indexing) and that pages may wait in a rendering queue, sometimes longer than a few seconds. The same guide still calls server-side rendering or pre-rendering a great idea, because it makes pages faster for users and crawlers and because not all bots run JavaScript. For a public page that you want found, shipping real HTML is the lower-risk option.

If you do build public pages as an SPA, Google's guide gives specific rules worth following:

• Use real <a href> links and the History API for routing, not URL fragments, so Googlebot can discover your pages.
• Be careful setting noindex with JavaScript; Google says that when it sees a noindex tag it may skip rendering, so removing it later in JavaScript may not work.
• Avoid soft 404s: client-side routes that show a "not found" message but return HTTP 200. Google suggests redirecting to a URL that returns a real 404, or adding a noindex robots meta tag.
• Make sure titles, descriptions and canonical tags are present in the rendered output.

For pages behind a login, none of this matters: search engines cannot see them anyway. That is the main reason a logged-in dashboard can be a pure SPA with no SEO penalty. For the performance side of the same decision, see our guide to Core Web Vitals for web and mobile apps.

What the Next.js App Router changes

The App Router blurs the old SPA-or-SSR split. According to the Next.js documentation, Server Components render into a compact RSC payload, which is used together with Client Components to prerender HTML; the browser shows that HTML first and then hydrates only the Client Components. On later navigations the RSC payload is prefetched, so moving between pages feels like an SPA. With Cache Components (on by default for new apps created with create-next-app, according to the Next.js caching docs), a route is prerendered into a static shell and the parts that depend on the request stream in behind <Suspense> boundaries. Next.js calls this Partial Prerendering.

The Next.js docs also say it fully supports building SPAs: you can start as a static export (output: "export") and add server features later. The trade-off is that a static export cannot use features that need a server, which the docs list as including cookies, rewrites, redirects, headers, Proxy, incremental regeneration, default image optimisation, Server Actions and dynamic routes without generateStaticParams().

Costs and complexity

In our experience the hidden cost of the App Router is the learning curve around the server/client boundary and caching rather than hosting bills. The hidden cost of a pure SPA is usually performance on first load and the effort of building a separate public site. Both are manageable if you decide deliberately.

A practical recommendation

1. If you have a public marketing site and an app, use one Next.js App Router project: static pages for marketing and docs, Server Components for data-heavy app pages, and Client Components for interactive widgets.
2. Keep "use client" at the leaves. The Next.js docs recommend adding it to the files that define interactive components rather than marking large parts of the UI as client code.
3. For a heavy editor, load it as a client-only component inside the app and keep the surrounding pages server-rendered.
4. If your product has no public pages and your team prefers it, a Vite and React SPA with a separate API is simpler and entirely reasonable.
5. If marketing is run by non-developers in a CMS, consider a separate marketing site; see WordPress vs Next.js.

When a different approach makes sense

If you are migrating an existing SPA, you do not need a rewrite; the Next.js docs describe incremental migration paths from Create React App and Vite. If your team works in Rails, Laravel or Django, server-rendered HTML with a small amount of client-side JavaScript remains a productive pattern for many SaaS apps. Our SaaS tech stack decision guide covers those options. If you would like help structuring an App Router project, our Next.js development team does this work; for a small app, following the Next.js documentation's own guides is usually enough.