SPA vs SSR vs Static Site: What to Choose

Before any framework conversation, the more useful question is when the HTML the user sees actually gets produced. There are three honest answers, and the choice between them shapes performance, SEO, hosting cost and operational complexity for the life of the project.

The HTML can be produced at build time: every page is rendered once, when you deploy, into static files that sit on a CDN. The user gets HTML the instant the request lands. The cost is that anything dynamic has to be added on top.

It can be produced at request time: every time a user hits a URL, a server runs code, fetches whatever data it needs, and renders the page. The user gets a fresh HTML per request. The cost is the server has to be there, running and warm, for every page view.

It can be produced at client time: the server sends a near-empty HTML shell with a JavaScript bundle, the browser downloads and runs it, and the page appears once the bundle has executed. The user gets a slow first paint, then a very interactive app. The cost is everything between landing and running.

Most "SPA vs SSR vs static" debates are really about which of these three timing options fits the project. Picking a framework first and backing into a rendering mode is how teams end up paying for capabilities they did not need or missing capabilities they did. The framework-specific version of this conversation, applied to Next.js, is in the when-to-use Next.js article.

Static site generation produces every page at deploy time. The output is plain HTML, CSS, JavaScript and assets that can be served from a CDN with no application server in between.

This is the right mode when the content is largely the same for every visitor and changes on a schedule that the team controls (publishing a blog post, updating a marketing page, shipping a new product description). It gives the fastest possible first paint, the cheapest possible hosting (a CDN bill, not a Node bill), and the simplest possible operational model (if the deploy worked, the site works). For SEO on stable content, nothing beats it.

The trade-offs are equally clear. Anything that depends on data the team did not have at build time has to come in after the page loads, via client-side JavaScript or an API call. If the dataset changes often, build times grow with it: a 50-page site builds in seconds, a 50,000-page catalogue in minutes or longer. And personalisation per visitor (logged-in state, location-aware content) does not fit the model without help from the edge or the client.

Server-side rendering runs application code for each request and returns fully formed HTML. The user gets a complete page on first paint, with whatever fresh data the request asked for: latest stock, latest prices, content filtered for the user's region, the user's own dashboard.

This is the right mode when freshness or per-request context matters at the level of the HTML, and when SEO still has to work. A logged-in dashboard rendered server-side gives a fast first paint and a real URL the search engine never needed to see anyway. A multilingual content hub rendered server-side delivers the right locale's HTML before any JavaScript runs.

The trade-offs are operational. A server has to be running. It has to be warm enough to handle the spike. The hosting bill grows with traffic in a way a CDN bill does not. Caching strategies (edge cache, full-page cache with revalidation, per-route cache rules) are part of the design, not a launch-week problem. Get the cache strategy right and SSR scales fine; get it wrong and the rendering server becomes the bottleneck of the whole site.

A single-page application sends a near-empty HTML shell and a JavaScript bundle to the browser. The browser downloads the bundle, runs it, fetches data, and paints the page. After that initial cost, navigation between routes is fast because no full page reload is needed.

This is the right mode for applications, not websites. A logged-in product (a CRM, a dashboard, an editing tool) where SEO does not apply, the user is going to spend twenty minutes inside the app, and the cost of the initial bundle is amortised over a long session. Once it has loaded, the experience is closer to a native app than to a web page.

The trade-offs are everything between landing and running. First paint is slow, especially on poor connections. SEO is hard, because the crawler sees the empty shell unless extra work is done. Time to interactive depends on the bundle size, which only grows. Routing depends on JavaScript working, which means a broken bundle breaks the whole site. None of these are dealbreakers for the apps that fit the SPA shape; they are dealbreakers for the websites that do not.

The pure forms above are useful for thinking, but few real projects sit cleanly inside one of them. A typical mature setup combines all three, and that is usually correct.

The marketing pages are static (rendered at build, served from CDN, fast and cheap). The content pages with dynamic data are server-rendered (filtered catalogues, multilingual hubs, location-aware pages). The logged-in app behind the login wall is a SPA (or close to it), because SEO does not matter inside it and the session is long enough to amortise the bundle cost.

Modern frameworks (Next.js, Remix, Astro, SvelteKit) are designed around this hybrid. Incremental static regeneration lets a static site refresh individual pages on a schedule without rebuilding everything. Islands architecture lets static pages contain small interactive components that hydrate independently. React Server Components push the boundary further by deciding per-component whether to render on the server or the client. The good news is that the rendering mode no longer has to be chosen for the whole site. The bad news is that picking it per page or per component requires more design discipline, not less.

Three questions cover most of the choice in practice.

Does the page need to be discoverable by search engines, with content that depends on dynamic data? If yes, build-time or request-time rendering is the floor. SPA-only is not the right answer for SEO-critical content with dynamic data, regardless of how clever the workaround is.

Does the content for a given URL change for every visitor, or on a predictable schedule? Per-visitor content (logged-in state, personalisation, search results) wants request-time rendering or client-time rendering. Predictable-schedule content (blog posts, marketing pages, product descriptions that update weekly) wants build-time rendering with a periodic refresh.

What does the team actually run in production today? Static hosting on a CDN is operationally cheaper than a Node server, which is operationally cheaper than a browser-heavy SPA with a separate API. Architecture decisions that ignore the team's existing operational model age badly. The technical-SEO and performance side of these decisions, including how rendering mode interacts with Core Web Vitals, sits inside the wider technical performance discipline.

SPA, SSR and static site generation are not competing trends. They are three answers to the question of when the page gets produced, and modern projects routinely use all three inside one codebase. The mistake is to treat the rendering mode as a framework feature; it is a project decision that should drive the framework choice, not the other way around. Pick the rendering mode that fits the content, the SEO, the team and the hosting model, and most of the framework debate becomes simpler.

The wider context, including how rendering choices connect to architecture, performance and content strategy, is collected in the web architecture and platforms insights cluster. And when the question moves from "what rendering mode should we pick" to "we have picked, and we now need someone to ship it well, with the SEO, the Core Web Vitals and the hosting model that match", that is exactly what my technical SEO and web performance practice is built around.