How is RSC (React Server Components) different from SSR (Server Side Rendering)?

The foundational difference is that RSC renders components exclusively on the server to eliminate JavaScript bundle size and enable direct backend access, while SSR is a page-level strategy that generates initial HTML on the server but still sends component code to the client for hydration.

The key difference lies in their objectives and technical implementation: SSR is a page-level rendering strategy that converts the entire React component tree into HTML on the server to improve initial load time, but it still sends component JavaScript bundles to the client for hydration to make the page interactive . RSC, introduced in React 19, takes a component-level approach where specific components run exclusively on the server, never ship their code to the client, and communicate via a special serialized format rather than HTML .

1
Execution Location: SSR runs on the server during the initial request to generate HTML, but the same component code also runs on the client during hydration. RSC runs exclusively on the server - its code never reaches the browser .
2
Output Format: SSR produces raw HTML strings that the browser parses and displays. RSC produces a specialized serialized format (JSON-like tree description) that preserves component boundaries and allows seamless merging with Client Components .
3
Bundle Impact: SSR includes component JavaScript code in client bundles for hydration, impacting bundle size. RSC sends zero JavaScript for Server Components - only Client Components (marked with 'use client') ship their code, dramatically reducing bundle size .

SSR vs RSC Implementation Comparison

RSC components can directly access databases, file systems, or any server-only APIs without creating intermediary API endpoints . In SSR, data fetching is typically separated from component rendering (e.g., getServerSideProps in Next.js Pages Router), creating an additional layer of abstraction. This direct server access in RSC eliminates "request waterfalls" where components wait for client-side data fetching after initial load .

1
SSR Hydration: After the HTML loads, React hydrates the entire component tree, making all components interactive. This requires loading and executing component JavaScript, which can delay Time to Interactive .
2
RSC Selective Hydration: Only Client Components marked with 'use client' hydrate. Server Components never hydrate and cannot use useState, useEffect, or event handlers . This reduces JavaScript execution on the client significantly.

Both technologies support streaming, but differently. SSR with modern React supports renderToPipeableStream, which streams HTML to the client progressively. RSC naturally supports streaming by sending component output as it resolves, and when combined with SSR (as in Next.js App Router), it creates the optimal architecture: RSC for data fetching and component composition, SSR for generating the initial HTML payload .

RSC is not a replacement for SSR but a complementary technology. In Next.js App Router, Server Components (RSC) handle data fetching and static content, while SSR is used to generate the initial HTML sent to the browser. This creates a hybrid architecture where you get the bundle size benefits of RSC with the first-paint speed of SSR . The main cost is increased complexity in understanding the server-client boundary and managing which components run where .

Difficulty: 5/10

Topics: rendering model, data fetching, performance

Scenario Questions

0-2 years experience

1
If you need to display a list of products that includes user‑specific pricing, would you choose a React Server Component or a traditional SSR page, and why?
2
What happens when you import a server component inside a client component? How does the rendering differ from a typical SSR page?
3
How would you fetch data inside a React Server Component compared to using getServerSideProps in an SSR route?

2-5 years experience

1
We added an analytics tracking hook inside a component that was originally a server component, and the page stopped rendering. Walk me through why that happened and how you'd fix it.
2
During a feature rollout you notice a server component is sending a large JSON payload to the client, causing latency. How would you diagnose and mitigate the issue compared to SSR?
3
Explain the trade‑offs of using RSC for a dashboard that needs frequent real‑time updates versus using SSR with client hydration.

5-8 years experience

1
Design a hybrid rendering strategy for an e‑commerce site where product detail pages use RSC but checkout uses SSR. What edge cases do you need to handle regarding data consistency and caching?
2
At scale, how do React Server Components affect server memory and CPU compared to SSR when many users request personalized content? What mitigations would you put in place?
3
If a third‑party library only works in the browser, how would you integrate it into a page that primarily uses RSC without falling back to full SSR?

8+ years experience

1
Your organization is migrating a large legacy Next.js app from SSR to RSC. What architectural changes, team processes, and backward‑compatibility concerns would you address?
2
How would you evaluate the long‑term maintenance cost of adopting RSC across multiple micro‑frontends compared to staying with SSR, considering versioning, testing, and deployment pipelines?
3
In a multi‑tenant SaaS platform, how would you design data fetching and caching layers to support both RSC and SSR components while ensuring tenant isolation and performance?

Follow-up Questions

❓Can you give an example where SSR would still be the better choice?
❓How does the choice between RSC and SSR affect the client bundle size?
❓What are the implications for hydration in each approach?