React Server Components (RSC) differ from traditional SSR by focusing on component-level rendering without client-side JavaScript, while traditional SSR hydrates entire pages; they work together seamlessly—RSC handles data fetching and rendering, while SSR provides the initial HTML shell
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.
Output format: Traditional SSR produces HTML; RSC produces a special binary format (RSC Payload) that describes the component tree with client component references.
JavaScript shipping: Traditional SSR ships component code to client for hydration; RSC ships zero JavaScript—only the rendered output reaches the client.
Re-rendering: Traditional SSR requires full page reloads or client-side routing with data fetching; RSC Payload enables seamless navigation with server-side rendering preserved.
Data fetching: Traditional SSR uses getServerSideProps or similar at page level; RSC allows data fetching inside any component with async/await.
Execution environment: Both run on server, but RSC maintains a persistent component tree across requests through the RSC Payload.
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.
What it contains: The RSC Payload is a compact binary representation of the Server Component tree, including rendered output of Server Components and references to where Client Components should be mounted.
How it's used: During initial load, it's used alongside HTML for hydration. During navigation, it's fetched directly to update the UI without full page reloads.
Size advantage: Because it doesn't include component code, only rendered output, it's much smaller than sending JavaScript bundles.
Streaming support: The payload can be streamed incrementally as Server Components resolve, enabling Suspense boundaries to populate progressively.
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.
Initial page load: RSC alone doesn't produce HTML—it needs SSR to generate the initial HTML for fast First Contentful Paint and SEO.
Search engine crawlers: While some crawlers execute JavaScript, HTML ensures reliable indexing across all search engines.
JavaScript-disabled environments: Users with JavaScript disabled still see content because HTML is present.
Performance budget: The initial HTML from SSR gives immediate content while RSC Payload loads in background.
Progressively enhanced apps: RSC with SSR creates applications that work without JavaScript and enhance when it loads.
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.