Server Rendering in 2026

Every few years the frontend pendulum swings. We moved rendering to the client for interactivity, then back to the server for speed, and somewhere in between a lot of well-intentioned apps got slower. After shipping a handful of production apps in both models, here's where I've landed.

What server rendering actually buys you

The arguments haven't changed much: first paint happens before a single byte of JavaScript parses, and content is readable by anyone with a browser. But the quieter win is resilience. If the bundle fails to load, your users still see the page. That alone is worth more than any benchmark.

The cost used to be interactivity. You rendered HTML on the server, then hydrated it with event handlers, and the gap between "page visible" and "page interactive" was a real UX tax.

Streaming changed the calculus

With streaming, the server doesn't have to finish rendering the whole page before sending anything. Slow sections — a query against a cold cache, a heavy chart — can yield to the client as HTML arrives, while interactive islands mount immediately.

// The slow data fetch no longer blocks the whole page.
export default function DashboardPage() {
  return (
    <Suspense fallback={<Skeleton />}>
      <RevenueChart />
    </Suspense>
  );
}

The component above streams in when its data is ready; the rest of the page is already interactive. That's the mental model I use now: render on the server by default, stream the slow parts, and reach for client components only where genuine interactivity lives.

When I still reach for the client

Forms with optimistic updates, drag-and-drop, anything tied to a canvas or a WebSocket — those are client concerns, and pretending otherwise makes code harder, not faster. The trick is keeping the boundary honest: the server renders what's shared and cacheable, the client owns what's local and mutable.

The pendulum will swing again. I'm just glad the default got sensible.