SSR vs SSG vs CSR: choosing a rendering strategy per route

"Should we use server-side rendering or a single-page app?" is usually the wrong question for a real application, because the right answer is rarely all-or-nothing. Most applications of any size genuinely benefit from using more than one rendering strategy — the actual decision is which strategy fits which route, not which one wins for the whole app.

The three strategies, in practical terms

Static Site Generation (SSG) renders a page once, at build time, and serves the same HTML to every visitor until the next build (or a scheduled revalidation). It is the fastest possible option — there is no server work happening per request — but the content is only as fresh as the last build.

Server-Side Rendering (SSR) renders the page on the server for every request, so the HTML is always current. This costs server time on every visit, but the content can reflect data that changes constantly — a logged-in user's dashboard, real-time inventory, personalized results.

Client-Side Rendering (CSR) ships a largely empty HTML shell and lets JavaScript running in the browser build the actual interface after the page loads. This is the traditional single-page-app model — flexible and interactive, but with a real cost: nothing meaningful is visible (or indexable by search engines, without extra work) until the JavaScript has downloaded and executed.

Matching strategy to route

Where teams get this wrong

Defaulting an entire application to one strategy. The most common mistake is picking CSR for everything because it is the familiar single-page-app pattern, then wondering why marketing pages rank poorly in search or load slowly on a weak connection. The reverse mistake also happens — forcing SSR on every route, including ones that never change, and paying server cost for work that build-time generation would have done once.

Treating "static" as "can never change." Modern frameworks support incremental static regeneration — a statically-generated page that re-generates itself in the background on a schedule, so visitors get fast, cached HTML most of the time, with content that still updates without a full redeploy. This fits a surprising number of routes that teams assume need full SSR.

Ignoring what "indexable" actually requires. A client-rendered page's content can, in principle, be crawled by modern search engines — but it is slower and less reliable than content that is already in the server-rendered HTML. For anything that needs to rank well in search, server-rendered or statically-generated content is the safer default, not an optimization to consider later.

A practical way to decide, per route

Ask three questions about a given page: Does it need to be found in search? Does its content change per request or per user? Does it sit behind authentication?

• Needs search visibility, content is mostly stable → SSG, with revalidation if it updates occasionally.
• Needs search visibility, content changes frequently or per request → SSR.
• No search requirement, heavily interactive, behind a login → CSR is usually fine, and often simpler to build.

The architecture decision that actually matters is making this choice deliberately, per route, rather than letting a framework's default or a team's habit decide it for the whole application.

If you are deciding on a rendering strategy for a specific project, tell us about it and we will give you a direct recommendation route by route, not a one-size-fits-all answer.