How do React Server Components (RSC) differ from traditional SSR? Can they be used together?

React Server Components (RSC) and traditional SSR operate at different layers and solve different problems, yet they complement each other perfectly. Traditional SSR generates HTML on the server and sends it to the client, where it's hydrated with JavaScript to become interactive. RSC, by contrast, is a data-fetching and rendering mechanism that produces a special serializable format (RSC Payload) that describes the component tree, but it doesn't generate HTML directly. In Next.js App Router, they work in concert: RSC runs on the server to fetch data and render components, producing both HTML (for initial page load) and the RSC Payload (for client navigation and hydration), giving you the best of both worlds—fast initial page loads with minimal JavaScript.

In Next.js App Router, RSC and traditional SSR aren't alternatives—they're integrated layers. When a request arrives, the server runs Server Components to generate the RSC Payload, then uses that payload to render the initial HTML (traditional SSR). This HTML is sent immediately, giving users a fast First Contentful Paint. Meanwhile, the RSC Payload is embedded in the HTML or streamed separately. On the client, React uses this payload to reconstruct the component tree without re-fetching data or re-running Server Components. When users navigate, the client fetches only the RSC Payload for the new route (not full HTML), enabling fast transitions while preserving the server-side data fetching model.

Traditional SSR sends JavaScript for the entire page, then hydrates everything—even static elements like headers and footers. RSC flips this model: only components explicitly marked with 'use client' ship JavaScript. A page with 90% static content and 10% interactive widgets might ship 90% less JavaScript than its Pages Router equivalent. This is possible because Server Components render on the server and their output becomes part of the RSC Payload, with no code ever reaching the client. The FollowButton example above: the button's JavaScript (useState, onClick) ships, but the user data and posts rendering logic never does.

In Next.js App Router, the rendering pipeline integrates both technologies seamlessly: When a request arrives, the server executes all Server Components in the route, generating the RSC Payload. Simultaneously, it renders this payload to HTML (traditional SSR). The HTML streams to the client immediately, while the RSC Payload follows. On the client, React uses the HTML for initial paint, then hydrates using the RSC Payload—but only hydrates Client Components. For subsequent navigations, the client fetches fresh RSC Payload directly from the server, skipping HTML generation entirely. This gives you the best of both worlds: fast initial loads and efficient client-side transitions.

As React and Next.js evolve, the line between RSC and traditional SSR continues to blur. Partial Prerendering (PPR) extends the model by prerendering static shells at build time while keeping dynamic sections streaming. This combines SSG's performance with RSC's flexibility. In Next.js 16, concepts like 'Cache Components' are emerging to make caching declarative at the component level. The ultimate goal is a unified model where components declare their data and caching needs, and the framework automatically chooses the optimal rendering strategy—static, dynamic, or incremental—for each part of the page.