SSR was old before it was new again. The reason it returned has nothing to do with nostalgia and everything to do with the JavaScript tax becoming impossible to hide.
From 2013 to 2020 the React and Vue era taught a generation of developers to think of the page as a JavaScript application. The browser downloaded a bundle, the bundle constructed the DOM, the user waited. On a fast laptop with fiber the experience was fluid.
The mobile reality check
Most users do not have a fast laptop with fiber. They have a mid-range Android device on 3G in a metro area. The median JavaScript parse and execute time on that device is measured in seconds. By 2020 every performance audit told the same story: SPAs were leaving conversion on the table because the first interactive frame happened too late.
Core Web Vitals turned a cost into a metric
When Google made LCP, INP, and CLS ranking signals, performance stopped being a "nice-to-have hygiene" item and became a marketing line item. SEO teams started filing tickets. Product teams started prioritizing them. The economics flipped.
The new SSR is not the old SSR
SSR in 2026 looks nothing like CGI scripts. Today's stack is Next.js or Remix on a Node runtime, often with React Server Components, often deployed to a CDN edge. The server emits HTML for instant first paint, then hydrates only the interactive islands. The developer model is mostly the same as the SPA era; the runtime is split.
Streaming and partial prerendering
The newest evolution is streaming HTML and partial prerendering. The server flushes the static shell first, then streams interactive sections as data resolves. From the user's perspective, the page feels alive in milliseconds.
Trade-offs that remain
Server rendering means you need a server. That is an operational tax pure SPAs avoid. Cold starts, edge deployment costs, and observability for distributed render paths are all real. But for product teams that need to win Core Web Vitals and SEO, the math is now clearly on the SSR side.