SPA vs SSR: Client-Side vs Server-Side Rendering for Web Apps

Daniel Reyes AI & Engineering Lead, YuSMP Group · Architecting AI integrations for enterprise clients in the US and EU since 2019

Every web product has to answer one architectural question early: where does the HTML get built? In a single-page application (SPA), the server sends a nearly empty shell and the browser builds the interface with JavaScript. With server-side rendering (SSR), the server sends a finished page and the browser makes it interactive afterwards. The choice affects how fast users see content, how search engines and AI assistants read your pages, what you pay for hosting and how your team works.

Most SPA vs SSR articles stop at “SSR is better for SEO, SPAs are better for interactivity”. That is true but incomplete. In practice the decision turns on which routes must be public and indexable, how much JavaScript you ship, whether AI crawlers need to read your content, and how much server infrastructure your team is ready to run. These are the questions we work through at the start of any web application development project.

This guide covers the basics, then goes further: how Google and AI crawlers actually treat JavaScript, the hidden performance cost of hydration, hybrid rendering with React Server Components, streaming and islands, a cost comparison and a step-by-step path from an existing SPA to SSR without a rewrite.

TL;DR: SPA or SSR?

• SPA strengths: app-like navigation after the first load, simple static hosting on a CDN, a clean split between frontend and API.
• SSR strengths: content in the initial HTML, faster first paint on most devices, reliable indexing by Google and readability by bots that do not run JavaScript.
• SSR’s hidden cost: server runtime, caching rules and hydration work in the browser, which can hurt responsiveness if you ship too much JavaScript.
• The 2026 default: hybrid — server-rendered or static public routes, client-rendered application routes behind login.

What is a single-page application (SPA)?

A single-page application is a web app that loads one HTML document and then renders and updates the whole interface in the browser with JavaScript. This approach is called client-side rendering (CSR). When a user clicks a link, the SPA does not request a new page from the server; a client-side router swaps components and changes the URL with the History API, and the app fetches only the data it needs from an API.

SPAs became mainstream with frameworks such as React, Vue and Angular, typically bundled today with a build tool such as Vite. The server side of an SPA is simple: a CDN serves the static shell, JavaScript bundles and assets, and a separate backend exposes REST or GraphQL endpoints. The same API can then serve web, iOS and Android clients.

Typical SPA users are products where people log in and stay for a long session: analytics dashboards, CRMs, admin panels, project-management tools, design and document editors, internal enterprise tools and the logged-in part of most SaaS products. For these apps, the first load happens once per session, and what users notice is how quickly screens respond afterwards.

How client-side rendering works

1. The browser requests a URL and receives a small HTML shell, usually an empty root element and script tags.
2. The browser downloads, parses and executes the JavaScript bundle.
3. The app calls one or more APIs to fetch the data for the current screen.
4. JavaScript builds the DOM and the user finally sees meaningful content.
5. Later navigations are handled in the browser: only data is fetched, and the page is not reloaded.

The trade-off is visible in steps 2–4: until the bundle is loaded and the data has arrived, the user, a crawler or an AI bot sees little or nothing. As the app grows, the bundle tends to grow with it.

What is server-side rendering (SSR)?

Server-side rendering means the server builds the full HTML for a page on each request and sends it to the browser ready to display. JavaScript then loads and “hydrates” the page, attaching event handlers and state so it becomes interactive. The user sees content first and interactivity follows.

Classic server frameworks — PHP, Rails, Django — always rendered on the server. What is different today is that modern meta-frameworks render the same component code on the server and in the browser: Next.js and Remix for React, Nuxt for Vue, SvelteKit for Svelte, and Angular’s own SSR support. You write one set of components; the framework decides where each part runs. If you are choosing between two of these, our Next.js vs Nuxt comparison covers that decision separately.

SSR needs a server runtime — Node.js, an edge function platform or another server — because HTML is produced per request. That runtime can read cookies, check sessions and fetch data close to the database before the page leaves the server.

How SSR and hydration work

The Next.js documentation describes the first load of a modern SSR app in three stages, and the sequence is similar in other frameworks:

1. The server renders the route and sends HTML, so the browser can show a fast, non-interactive preview immediately.
2. A serialized description of the server-rendered component tree (in Next.js, the React Server Components payload) is used to reconcile the client and server trees.
3. JavaScript downloads and hydrates the interactive components, which then respond to clicks and input.

In the Next.js App Router, subsequent navigations happen on the client using a prefetched payload — so an SSR app can feel like an SPA once it has loaded. That convergence is why the SPA vs SSR question in 2026 is less about frameworks and more about which routes need which behaviour.

SPA vs SSR: head-to-head comparison table

The table summarises how a client-rendered SPA and a server-rendered app compare on the criteria that decide real projects. Values are qualitative and reflect typical implementations; well-optimised and poorly optimised versions of each exist. Each row is explained in the sections that follow.

Read the table as a list of trade-offs, not a scoreboard. Most of the SSR advantages concern public pages and the first visit; most of the SPA advantages concern long sessions behind a login.

Is SSR better than SPA for SEO?

Yes, for pages that need to rank, SSR or static rendering is the safer choice, because the content, links and metadata are in the HTML before any JavaScript runs. Google can index client-rendered SPAs, but it does so later and with more ways to go wrong.

According to Google’s JavaScript SEO basics, Googlebot processes JavaScript pages in three phases: crawling, rendering and indexing. Pages that return HTTP 200 are queued for rendering, and a headless Chromium instance executes the JavaScript before the rendered HTML is indexed. Google notes that a page may stay in this render queue for a few seconds, “but it can take longer than that”. For a large catalogue with frequently changing content, that delay matters.

Google also describes dynamic rendering — serving pre-rendered HTML to bots and the SPA to users — as a workaround rather than a recommended long-term solution. It adds infrastructure, and the bot version can drift from what users see.

Rendering is not the only SEO risk in an SPA. The common failures are more mundane:

• Links that are not links. Navigation built with click handlers on <div> or <button> elements gives crawlers nothing to follow. Use real <a href> elements with crawlable URLs.
• Metadata injected only by JavaScript. Titles, descriptions, canonical tags and structured data set after load may be missed or read late, and social-preview bots usually do not run JavaScript at all.
• Soft 404s. An SPA often returns HTTP 200 for every URL and shows “not found” in the client, which confuses indexing.
• Content behind interactions. Text that loads only after scrolling, tabs or clicks may never be rendered by a crawler.

If you must keep a client-rendered architecture, the mitigations are well known: prerender public routes at build time, generate marketing pages statically, return correct status codes, put metadata in the server-delivered HTML and keep URLs clean. At that point, however, you are already doing part of what SSR or static generation would give you by default.

For pages behind a login, none of this matters: search engines cannot and should not index them, so SEO is not an argument for SSR there.

SPA vs SSR for AI search: can ChatGPT and Claude read your app?

Generally, AI search crawlers cannot read content that appears only after client-side rendering, because they do not execute JavaScript. That makes rendering strategy an AI visibility question as well as an SEO one.

Vercel analysed AI crawler traffic across its network and published the results in “The rise of the AI crawler” in December 2024. As of that analysis, none of the major AI crawlers rendered JavaScript — including OpenAI’s GPTBot, OAI-SearchBot and ChatGPT-User, as well as Anthropic’s ClaudeBot. They downloaded JavaScript files but did not execute them. Vercel’s recommendation was direct: because ChatGPT and Claude do not execute JavaScript, any important content should be server-rendered.

In practice, this affects specific page types:

• Product and feature pages that buyers ask assistants to compare.
• Pricing pages, which are among the most frequently requested facts about any SaaS product.
• Documentation, help centres and API references, which developers increasingly query through AI tools.
• Blog posts, guides and case studies that you want cited as sources.

Crawler capabilities change, and Google’s own crawler does render JavaScript. Still, designing public content to be readable without JavaScript is cheap insurance that works for every bot. The logged-in application is unaffected: AI crawlers cannot access it either way, so a client-rendered dashboard loses nothing here.

Which is faster: SPA or SSR?

SSR is usually faster to show content on the first visit, and an SPA is often faster when moving between screens afterwards. Which one “feels” faster depends on the page type, the device, the network and, above all, how much JavaScript you ship.

Google’s web.dev guide Rendering on the Web lays out the trade-offs. Server-side rendering generally produces a fast First Contentful Paint (FCP) and can reduce Total Blocking Time (TBT) and Interaction to Next Paint (INP), because less work happens in the browser. However, generating pages on the server takes time, which “can increase your page’s TTFB” (Time to First Byte). Static rendering avoids that cost and gives a consistently fast TTFB, but it only works when URLs are known ahead of time.

Client-side rendering has the opposite profile. The static shell arrives quickly, but meaningful content waits for the bundle and the data. web.dev notes that with CSR “the amount of JavaScript required tends to grow” as an application grows, which delays FCP and Largest Contentful Paint (LCP) and makes INP worse, especially on mid-range phones. For a deeper look at the metrics themselves, see our guide to web app performance and Core Web Vitals in 2026.

The hidden cost of hydration

SSR is often presented as simply “faster”. The catch is hydration. After the server sends HTML, the browser still has to download the JavaScript for the page and run it to make the HTML interactive. Until that finishes, the page can look ready but ignore taps and clicks. web.dev warns that hydration “can have a significant negative impact on TBT and INP, even if it improves FCP”.

The practical consequence: an SSR app that hydrates its entire page with a large bundle can score well on FCP and LCP and still feel sluggish. The fixes are about shipping less client JavaScript — keeping non-interactive parts on the server, hydrating only interactive components, splitting code by route and using streaming. web.dev’s own recommendation is to consider server-side or static rendering over a full rehydration approach.

Where SPAs still feel faster

• Long sessions. Once the bundle is cached, every subsequent screen needs only data, so navigation can be close to instant.
• Highly interactive views. Drag-and-drop, live filtering, canvas editors and real-time collaboration update locally without a server round-trip.
• Optimistic updates. The UI can reflect a user’s action immediately and reconcile with the server in the background.

The honest summary: measure your own critical routes with field data, on the devices your users have, before and after any rendering change. Treat any generic “SSR is X% faster” claim as context-specific.

When should you choose an SPA?

Choose an SPA when the application lives behind a login, users stay for long sessions and rich interactivity matters more than first-load speed or search visibility. These are the situations where we usually recommend client-side rendering:

When should you choose SSR?

Choose SSR when pages are public, must be found in search or cited by AI assistants, and need to show content quickly to first-time visitors. These are the situations where server rendering usually pays off:

Do you have to choose? Hybrid rendering in 2026

No — in 2026 most serious web products do not choose one rendering mode for the whole app. Modern meta-frameworks let you pick a strategy per route, and even per component, so public pages can be static or server-rendered while the logged-in product behaves like an SPA.

SSG and ISR for pages that rarely change

Static site generation (SSG) renders pages once at build time and serves plain HTML files from a CDN. web.dev describes it as giving a consistently fast TTFB, at the price of needing to know URLs ahead of time. Incremental static regeneration (ISR), popularised by Next.js and available in similar forms elsewhere, rebuilds individual static pages in the background after a set interval or on demand, so large catalogues can stay mostly static without full rebuilds. For blogs, documentation, marketing pages and slowly changing product pages, static rendering is often the cheapest and fastest option of all.

Streaming SSR and React Server Components

Streaming SSR sends HTML in chunks as data becomes available, so the browser can render the page shell and the fastest sections first instead of waiting for the slowest query. web.dev pairs it with progressive rehydration, where interactive parts become live one by one rather than all at once.

React Server Components push the idea further. According to the Next.js documentation, layouts and pages in the App Router are Server Components by default: they run only on the server, can read data directly and send no component JavaScript to the browser. You opt individual components into the client with the "use client" directive, which marks the boundary where hydration starts. After the first load, navigations happen on the client with prefetched payloads. The result is SSR for the first visit, SPA-like navigation afterwards and far less JavaScript than hydrating the whole page.

Islands architecture

Islands architecture, used by Astro, starts from the opposite default: pages are static HTML, and only explicitly marked interactive components (“islands”) load JavaScript and hydrate. It is a strong fit for content-heavy sites with a few interactive widgets — a pricing calculator, a search box, a signup form.

Per-route strategy: public routes server-rendered, app routes client-rendered

The most practical hybrid pattern is simple to state:

• Marketing pages, blog and docs: static generation, rebuilt on publish.
• Catalogue, listings and pricing: SSR or ISR with CDN caching.
• Signup and onboarding: server-rendered forms with progressive enhancement.
• Logged-in product: client-rendered, SPA-style, with client-side routing and local state.

You can implement this in one meta-framework, or split it into two deployments — a static or SSR site and a separate SPA on an app subdomain. One codebase is easier to share components across; two deployments are easier to scale and release independently. Our Next.js vs React guide for B2B web apps and the 2026 web app tech stack guide cover the framework side of that decision.

SPA vs SSR: cost and timeline comparison

An SPA is usually cheaper to host and simpler to operate, while SSR adds server, caching and observability work but can save marketing and SEO effort later. The table shows relative effort by work item. These are YuSMP planning heuristics for a senior team working from a scoped brief, not market statistics; your numbers depend on traffic, domain complexity and team experience.

The rendering choice rarely dominates a project budget: features, integrations and design usually do. Where it does matter is long-term running cost. A client-rendered dashboard can run on static hosting for years with almost no infrastructure work. A server-rendered catalogue with heavy traffic needs capacity planning and caching, but it can replace separate prerendering tools and a separate marketing site. For full budgets and schedules, see our guides to custom web app development cost and how long it takes to build a web app in 2026.

How do you move from SPA to SSR without a rewrite?

You migrate route by route: server-render or prerender the public pages that need to be indexed, and leave the logged-in application client-rendered. A full rewrite is rarely necessary and rarely a good use of budget.

1. Audit routes by one question: must this be indexable? List every route and mark it public or private. Public routes with search or AI value move first; private routes may never need to move.
2. Prerender or statically generate marketing pages first. Home, pricing, features and blog are usually low-risk and give the quickest SEO and AI visibility win.
3. Move public routes to a meta-framework incrementally. For a React SPA, Next.js or Remix can host the new public routes while a reverse proxy or CDN routing rule still sends application paths to the existing SPA. Vue teams can do the same with Nuxt.
4. Keep the authenticated app client-rendered. Reuse components and design tokens, but do not force dashboards into SSR without a measured reason.
5. Fix browser-only code. Anything that touches window, document or localStorage fails during server rendering. Move it into client components or effects that run only in the browser, and watch hydration-mismatch warnings.
6. Measure Core Web Vitals before and after. Compare field data for LCP, INP and CLS on the migrated routes, and check that the server-delivered HTML contains the content, links and metadata you expect.

The main risks are duplicated routing logic during the transition, authentication cookies that need to work on both stacks, and accidentally exposing secrets: in Next.js, only environment variables prefixed with NEXT_PUBLIC_ are included in the client bundle, so keep server-only keys unprefixed and review what each boundary sends to the browser.

Common mistakes when choosing between SPA and SSR

Most rendering decisions that go wrong fail because the choice was made for the whole product instead of per route, or because JavaScript weight was ignored. These are the mistakes we see most often:

• SSR for a logged-in dashboard. Paying for server rendering, caching rules and hydration complexity on pages no crawler will ever see.
• An SPA for an e-commerce catalogue. Product and category pages that depend on JavaScript to show content, with slower first paint and weaker indexing.
• Ignoring hydration and JavaScript weight. Choosing SSR and then hydrating every component on the page, which moves the performance problem from FCP to INP.
• Relying on dynamic rendering long term. Serving bots a separate prerendered version is a workaround with its own maintenance and drift risks.
• Meta tags injected only by JavaScript. Titles, canonicals, Open Graph tags and structured data should be in the server-delivered HTML.
• Leaking secrets into the client bundle. Prefixing API keys for client access or importing server modules into client components can publish credentials to every visitor.

How YuSMP Group approaches rendering architecture

We don’t start with a preferred framework. We start with a route map: every page of the product, marked public or private, with its SEO and AI visibility value, data freshness requirements and expected traffic. That map usually makes the SPA vs SSR decision obvious route by route, and we record it as an architecture decision before the first component is built.

From there we set a performance budget for the key routes — LCP, INP and the JavaScript shipped per page — and choose the framework that meets it with the least operating overhead. Often that is a meta-framework with static and server-rendered public routes and a client-rendered app area; sometimes it is a static site plus a separate SPA. Our React development and Next.js development teams apply this process end to end, with monitoring of Core Web Vitals and hydration errors from launch.

FAQ

Is SSR better than SPA?

Neither is better in every case. SSR is better for public pages that must rank in search, be readable by AI crawlers and show content quickly on first load, such as product pages, documentation and marketing sites. An SPA is better for logged-in, highly interactive tools such as dashboards and editors, where SEO does not matter and fast in-app navigation does. Most products in 2026 use both, chosen per route.

Is an SPA bad for SEO?

Not automatically, but it is riskier. Google can render JavaScript, yet pages wait in a render queue, and many other bots never run JavaScript at all. An SPA whose content, links and meta tags appear only after scripts execute is harder to index reliably. If public pages matter for search, prerender them, generate them statically or server-render them, and keep the SPA for routes behind login.

Does Google index JavaScript single-page applications?

Yes. Googlebot crawls a page, queues it for rendering in a headless Chromium browser and then indexes the rendered HTML. Google says a page may stay in that queue for a few seconds but it can take longer. Google still recommends server-side rendering or pre-rendering because it is faster for users and crawlers, and because not all bots can run JavaScript.

Can AI search engines like ChatGPT read client-side rendered pages?

Usually not. According to an analysis Vercel published in December 2024, none of the major AI crawlers, including the OpenAI and Anthropic bots, rendered JavaScript at that time. They download script files but do not execute them. Content that appears only after client-side rendering is therefore invisible to them. Product, pricing and documentation pages should deliver their content in the initial HTML.

Is SSR slower than SPA?

It depends on what you measure. SSR usually shows meaningful content sooner on the first visit, which helps First Contentful Paint and Largest Contentful Paint, but rendering on the server can increase Time to First Byte. An SPA is often slower on first load because the browser must download and run JavaScript first, yet it can feel faster when moving between screens afterwards. Measure your own key pages.

What is hydration and why does it matter?

Hydration is the step where JavaScript runs in the browser and attaches event handlers and state to HTML that the server already rendered, making it interactive. It matters because the page can look ready before it responds to clicks. Large hydration work can hurt Total Blocking Time and Interaction to Next Paint even when it improves First Contentful Paint, so ship less client JavaScript.

What is the difference between SSR and SSG?

SSR builds the HTML on the server for each request, so content can be fresh and personalized. SSG, static site generation, builds the HTML once at build time and serves the same files from a CDN, which gives a consistently fast Time to First Byte and low hosting cost. SSG needs URLs known ahead of time. Incremental static regeneration sits between them by rebuilding static pages periodically.

Is Next.js SSR or SPA?

Both. In the Next.js App Router, layouts and pages are Server Components by default, so the first load arrives as server-rendered HTML. Components marked with the use client directive are hydrated in the browser, and later navigations happen on the client using prefetched payloads, which feels like an SPA. Next.js can also generate static pages, so one app can mix strategies per route.

Can I convert an existing React SPA to SSR?

Yes, and usually without a full rewrite. Start with the public routes that need to be indexed, move them to a meta-framework such as Next.js or Remix, or prerender them, and keep the logged-in application client-rendered. Expect to fix code that uses browser-only APIs such as window and localStorage during server rendering, and measure Core Web Vitals before and after each step.

Verdict: SPA or SSR for your web app?

In 2026, SPA vs SSR is not a choice between an old and a new technology. Both are mature, and modern frameworks blur the line between them. The real decision is which of your routes need to be public, indexable and fast on first visit, and which need to be rich, long-lived applications.

• Choose an SPA if your product lives behind a login, users work in long sessions, interactivity or offline support matters most, and you already have, or want, a separate API serving several clients.
• Choose SSR or static generation if your pages must rank in Google, be cited by AI assistants, convert first-time visitors or show fresh catalogue data quickly on mobile.
• Choose a hybrid if you have both — which describes most SaaS, e-commerce and marketplace products: server-rendered or static public routes, a client-rendered app behind login and as little client JavaScript as each route allows.

A one-line decision rule: render on the server every page you want strangers, search engines or AI assistants to read, and render in the browser every page only your logged-in users will ever see.