Next.js or a React SPA? How to Choose for SEO, Speed and Budget

Most teams that start a web product in React hit the same question within the first week: do we build a single-page app, or do we use Next.js and render on the server? The honest answer is that neither is better in general. The right choice depends on who has to find the page, how often its content changes, and how much infrastructure you want to run.

This guide gives you a way to decide without reading ten framework comparisons.

What a single-page app actually does

A React single-page app (SPA) sends the browser a nearly empty HTML file and a JavaScript bundle. The browser downloads the bundle, runs it, calls your API, and only then draws the page.

Rule of thumb: if Google should find it, send HTML.

That has two consequences:

• The first view is slower, because nothing meaningful appears until the JavaScript has loaded and the data has come back.
• Search engines and link previews see less. Google can run JavaScript, but it does so in a second pass, and social previews and many other crawlers do not run it at all.

Neither point matters for a screen that sits behind a login. Both matter a lot for a marketing site, a blog or a product catalogue.

What server rendering changes

With server rendering, the HTML that reaches the browser already contains the content. The browser can show it straight away, and crawlers can read it without running any code. React then "hydrates" the page so it becomes interactive.

Next.js gives you three ways to produce that HTML:

Mode	When the HTML is built	Best for
SSG (static generation)	At build time	Pages that rarely change: landing pages, docs
ISR (incremental static regeneration)	At build time, then refreshed in the background	Blogs, catalogues, listings that change a few times a day
SSR (server-side rendering)	On every request	Pages that depend on the user or on live data

A simple decision path

flowchart TD
    A["Choose rendering strategy"] --> B{"Public and needs search traffic?"}
    B -->|No| C{"Behind a login?"}
    C -->|Yes| D["SPA"]
    C -->|No| E{"Changes per request?"}
    E -->|Yes| F["SSR"]
    E -->|No| G["SSG or ISR"]
    B -->|Yes| H{"Changes per request?"}
    H -->|Yes| F
    H -->|No| G

Read it top to bottom. If the page is private, a SPA is fine. If it is public and needs search traffic, you want HTML from the server, and the only remaining question is how fresh it must be.

Pick the cheapest mode that works. Usually that is SSG or ISR, not SSR.

What server rendering costs you

Server rendering is not free, and it is worth being clear about the trade-offs before you commit:

• You need a server. A pure SPA can live on any static host or CDN. SSR needs a Node runtime, which means monitoring, scaling and a bigger hosting bill.
• Caching gets harder. A static file caches trivially. A page rendered per request needs careful cache headers or you pay for every visit.
• More ways to get it wrong. Code that touches window or localStorage breaks on the server. Hydration mismatches produce flickers and console errors.
• A steeper learning curve for the team, especially around data fetching and the client/server boundary.

None of these are reasons to avoid Next.js. They are reasons to use the cheapest mode that meets your need, which is usually SSG or ISR rather than SSR.

When a SPA is the right call

Choose a plain SPA when:

1. The whole product sits behind authentication, such as an admin panel, a dashboard or an internal tool.
2. Nobody needs to find individual screens through search or share them as previews.
3. You want the simplest possible hosting and deployment.

Many successful products are exactly this. Adding server rendering to an internal dashboard adds cost and gives nothing back.

The hybrid most products end up with

The two options are not exclusive. A common and sensible setup looks like this:

Behind a login? A plain SPA is fine. Do not pay for what you do not need.

• Marketing pages and blog: SSG or ISR, so they are fast and fully indexable.
• Product pages and listings: ISR with a short revalidation time.
• The logged-in app: client-side rendering inside the same Next.js project, where the SPA trade-offs are acceptable.

One codebase, one deployment, and each page uses the mode that suits it.

A short checklist before you decide

• Who needs to find this page: users through search, or only people who already have the link?
• How often does the content change: monthly, daily, or per request?
• Does the page depend on who is looking at it?
• Do you already run servers, or is a static host a hard requirement?
• Does the team have experience with the client/server split?

If you answer "search" and "a few times a day", you almost certainly want ISR.

Conclusion

Pick the rendering mode per page, not per project. Public, content-heavy pages should arrive as ready-made HTML. Private, interactive screens can stay as a single-page app. At Inncode Systems we usually start new products with Next.js and static or incremental rendering for everything public, and keep the logged-in application client-rendered until there is a measured reason to change it.