Many developers confuse React Server Components (RSC) with Server-Side Rendering (SSR). While both run on the server, they solve entirely different problems.
SSR focuses on improving the initial page load speed by generating static HTML on the server. RSC focuses on reducing the JavaScript bundle size and making data fetching more efficient by rendering component layouts on the server and streaming data updates to the client.
Understanding the Execution Lifecycles
In a standard SSR app, the server runs your component tree, generates an HTML string, and sends it to the browser. The browser displays this static preview, downloads the JavaScript bundle, and runs the “hydration” process to make the page interactive.
In an RSC architecture, components are rendered into a serialized JSON-like format. This format describes the component tree layout and variables. The browser reads this stream, resolves dynamic endpoints, and updates the UI without needing to reload client state.
RSC: [ Server runs component ] ==[ Serialized stream ]==> [ Browser renders layout ]
(No client state lost)
Architectural Metric Breakdown
Here is a side-by-side comparison of RSC and SSR:
| Feature Category | Server-Side Rendering (SSR) | React Server Components (RSC) |
|---|---|---|
| Primary Output | Plaintext HTML strings | Serialized JSON layout stream |
| Client Hydration Cost | High (Processes the entire component tree) | Zero (Runs only on Client boundaries) |
| State Persistence | Lost during page navigations | Maintained dynamically across runs |
| Main Asset Cost | Full package bundles sent to client | Renders server dependencies, excludes JS |
| Ideal Use Case | Fast initial rendering and basic SEO | Data-heavy dashboards and complex workspaces |
By combining SSR for the initial paint and RSC for subsequent layout changes, you can build fast web applications that load quickly and remain interactive.