SPA Architecture: Rendering Strategies for Scale

You click a link in your SPA and nothing happens. Two full seconds of nothing. The URL changed. The previous page disappeared. A spinner materialized. Meanwhile, your JavaScript bundle is downloading, parsing, and executing before the browser can paint a single pixel of the content you asked for. An empty restaurant where the waiter hands you the recipe and expects you to cook. Blank white screen. Lighthouse scores crater. Core Web Vitals fail. And the team starts debating whether to “just add SSR” as if flipping a toggle on a quiet afternoon will fix an architectural decision baked into the foundation.

You cannot bundle-split your way out of a bad rendering decision.

The Four Rendering Strategies

Each one trades off build-time cost, server-time cost, and client-time cost. Two things decide which one fits: how often the content changes, and how personalized it is per request.

CSR makes sense for authenticated, interactive apps where search indexing doesn’t matter. Need crawlability? CSR is the wrong pick.

SSR wins when content is personalized per request but needs to be crawlable. The cost is server compute on every request. Plan for scaling from the start, or a traffic spike becomes a rendering outage.

SSG is the performance ceiling. Pre-built HTML from a CDN. The fastest LCP achievable. The constraint: any content change requires a rebuild. For content changing less than hourly with manageable page counts, SSG should be the default.

ISR bridges the gap. Statically generated, regenerated in the background when stale. A 60-second revalidation window is fine for catalogs. Unacceptable for a stock ticker. Know your freshness requirements before choosing.

The Hydration Problem

The server sends fully rendered HTML. The browser paints it. Then the page goes dead while React “hydrates,” re-attaching event listeners to the already-visible markup. The user sees a fully rendered page, clicks the checkout button, and nothing happens. They click again. And again. Rage-click five times and leave.

On a mid-range Android device over 4G, hydration can take over a second. Your LCP looks great because the HTML painted fast. Your INP tells the real story: the page looks ready but cannot respond to interaction.

Three approaches attack this from different angles:

Selective hydration (React 18+) wraps non-critical components in <Suspense>. React hydrates critical interactive elements first and defers the rest. The page feels interactive sooner because the browser prioritizes what the user can see and click.

Resumability (Qwik’s approach) serializes component state into HTML so the client resumes without re-executing JavaScript. Near-zero hydration cost in theory. In practice, the ecosystem is a fraction of React’s. Worth watching. Not production-ready for most teams today.

React Server Components skip the client entirely for non-interactive components. A product description that just renders text stays server-only. Zero client JavaScript for that component. Interactive components still hydrate, but the total JS needing hydration shrinks a lot on content-heavy pages.

Streaming SSR: Why TTFB Is Hostage to Your Slowest API

Traditional SSR waits for the entire page to render before sending any HTML. Three API calls at 50ms, 200ms, and 800ms? The browser waits 800ms before seeing a single byte. TTFB is hostage to the slowest dependency.

Streaming SSR sends HTML as each section resolves. The browser gets the shell and header while the recommendations API is still processing. TTFB drops from “slowest API call” to “first resolved section,” because the browser starts painting without waiting for every data source to finish.

Streaming breaks the dependency between TTFB and data fetching. Your slowest API call no longer holds the page hostage.

Remix’s loader pattern and Next.js App Router both handle streaming natively. Each route module exports a loader, the framework streams as data resolves. No manual chunk management.

Bundle Splitting That Works at Scale

The default output for a production React app is a single bundle. A mature application easily grows to hundreds of kilobytes gzipped. Your homepage visitor downloads the entire admin panel’s JavaScript. Route-based splitting is the highest-impact fix:

// Before: everything in one bundle
import Dashboard from './pages/Dashboard';
import Settings from './pages/Settings';

// After: each route is a separate chunk
const Dashboard = lazy(() => import('./pages/Dashboard'));
const Settings = lazy(() => import('./pages/Settings'));

This alone typically cuts the majority of initial bundle size. The browser downloads only the JavaScript for the current route. Subsequent navigation loads additional chunks on demand.

Component-based splitting adds value for heavy widgets that appear on some routes but not others. A rich text editor (200KB+), a charting library (150KB+), a map component (300KB+). The threshold: if a component adds more than 20KB gzipped to a chunk and is not visible above the fold, split it.

Below 20KB the HTTP request overhead outweighs the bundle savings. Twenty 5KB chunks perform worse than one 100KB bundle. Over-splitting is a real trap.

Core Web Vitals: Where Each Rendering Strategy Pays Its Tax

LCP suffers under CSR because JavaScript must execute before rendering. SSR and SSG remove the fetch-parse-execute chain from the critical path entirely. The improvement on mobile is measured in full seconds, often the difference between passing and failing Core Web Vitals thresholds .

INP takes hits from hydration and client-side routing transitions. A 300ms page transition blocks all interactions during that window. React 18’s startTransition marks navigation as non-urgent, keeping the UI responsive, but you have to opt in explicitly. It’s not the default.

CLS adds up from skeleton-to-content transitions, images without dimensions, and dynamic ads. Four layout shifts at 0.05 CLS each sum to 0.2. Fails the threshold. Death by a thousand small shifts, each one innocent in isolation.

Teams building single-page applications should default to SSR or SSG for public-facing pages and reserve CSR for authenticated sections where search indexing is irrelevant.

Server State vs Client State: Stop Caching API Responses in Redux

Server state (data from APIs) makes up most of the state in a typical application. Redux stores all of it, then you manually wire up caching, invalidation, loading states, and optimistic updates. For every endpoint.

React Query, SWR, and Apollo Client handle server state with caching, refetching, and optimistic updates built in. Switching from Redux for server state eliminates a large chunk of the store and the boilerplate surrounding it.

Redux still earns its place for genuinely client-side state: cart contents, form wizard progress, UI preferences that persist across navigation. If the Redux store is mostly API response caches, you are using a global state manager as a request library. Wrong tool.

Choosing a Framework by Workload

Next.js App Router: content-heavy sites needing ISR, middleware-based personalization, and mature React Server Component integration. The caching layers (router cache, data cache, full route cache) interact in non-obvious ways. Teams that do not understand all three will fight unexpected stale content.

Remix: data-heavy interactive applications. The loader/action model maps cleanly to CRUD operations. Streaming SSR is first-class. Fewer abstractions means fewer escape hatches, but also fewer sharp edges to discover six months in.

Vite + React Router: full control, zero opinions. Works for teams with strong frontend infrastructure engineers who want to own every architectural decision. A trap for teams that will rebuild half of Next.js ad hoc over 18 months.

For most product teams, Next.js or Remix gets you to production faster. Effective frontend UX engineering means choosing the framework whose opinions match your application’s actual requirements, not the one with the best conference talk.

Putting It Together: Per-Route Rendering

A mature SPA uses multiple strategies on the same site. Marketing pages: SSG. Product pages: ISR with a 60-second revalidation window. Search results: streaming SSR. Dashboard: CSR behind authentication. Both Next.js App Router and Remix support per-route strategy selection natively.

The W3C Paint Timing API measures the impact precisely. Use it to validate that each route’s rendering strategy actually delivers the LCP and INP numbers you expect. The gap between “should work” and “measured in production” is where performance regressions hide.

That two-second blank screen? With per-route rendering strategy, the same click paints content in under 300ms. Not faster code. The right rendering strategy stopped sending JavaScript to do HTML’s job.