Server-rendered or single-page? A plain answer

Written 8 July 2026. This one touches fast-moving tooling. The tradeoffs should hold; check anything version-specific against current documentation before relying on it.

Every few months the industry re-litigates this. The framework names change; the underlying tradeoff has not moved in ten years.

The two approaches, briefly

Server-rendered: the server sends finished HTML. The page appears fast and search engines can read it. Interactions typically involve a round trip.

Single-page: the browser downloads an application which then draws the pages. Slower to first appear, then very responsive, and it can hold complex state without asking the server again.

Everything else — the frameworks, the hybrid rendering modes, the streaming and the islands — is machinery for getting more of both, and it works. But the two questions below still decide which side you should start from.

Question one: does a stranger need to see it?

Anything a search engine or a first-time visitor must reach — marketing pages, property listings, articles, a product catalogue — should be server-rendered. Not because search engines cannot run JavaScript, but because speed on a phone on mobile data decides whether the visitor is still there, and shipping an application to someone who wanted to read a paragraph is a poor trade.

Question two: how long does someone stay?

A dispatch board someone watches for six hours has entirely different economics. One heavier initial load buys a day of instant interaction. That is a good deal, and a bad one for a visitor who arrived from Instagram and will leave in forty seconds.

In practice, most projects are both

The listings portal in our case studies is server-rendered on the public side and a single-page app behind the login. That is not a compromise, it is the correct answer: the two halves have different users with different needs.

Pick per surface, not per project. A marketing page and an operations console have nothing in common but a domain name.

What I would not do

• Ship a single-page app for a five-page brochure site. It happens constantly and it is always slower than the thing it replaced.
• Server-render a heavily interactive dashboard out of principle, then fight the framework for months.
• Choose based on what a conference talk said. The talk does not know who your visitors are or what network they are on.

Ask instead: who arrives here, on what connection, and how long do they stay? The answer picks the approach without any ideology being involved.

What “fast” actually means to the person waiting

Both camps claim speed, and both are telling the truth about different moments. It helps to name them.

• Time until something appears. Server rendering wins, usually decisively. The browser gets HTML and paints it.
• Time until it responds to a tap. This is where server-rendered pages can disappoint — the pixels arrived, the JavaScript that makes the menu work has not.
• Time for the next screen. A single-page app wins here, because it already has the code and often the data.

The gap that annoys users most is the second one: a page that looks ready and ignores you. It reads as broken in a way a visible spinner does not, and it is the specific failure of shipping a large JavaScript bundle to a mid-range phone.

The costs a single-page app adds

Beyond the initial download, choosing to render in the browser means taking on work the server used to do for free.

1. Routing. The back button, deep links and refresh all have to be made to work. They were free before.
2. Data fetching and caching. When to refetch, what to show while waiting, what to do when it fails. Every screen, forever.
3. Two places to keep in step. Validation rules, permissions and formatting now exist on both sides and can disagree.
4. Error handling in the browser. A server error page is automatic; a client-side crash shows a blank white screen unless you build for it.

None of these are reasons not to do it. They are reasons it costs more, and that cost should be paid for a screen that earns it rather than out of habit.

A decision table you can actually use

• Marketing pages, articles, listings, catalogues — server-rendered. Strangers arrive here from search and social.
• Dashboards, consoles, editors, anything behind a login — single-page. People stay, and interaction speed is the product.
• Checkout and forms — server-rendered with light interactivity. Reliability beats slickness where money is involved.
• Booking flows — either, but keep the first page fast; that is where people leave.

What I would ask before choosing

What device and connection does a typical user have? Do strangers arrive on this screen, or only people who logged in? How long is a session? Does search need to read it?

Four questions, and between them they decide it. Notice that none of them is about which framework is currently fashionable, which is what the argument is usually actually about.