Blog Post

Server Components aren't SSR!

1. The Two “Server” Ideas at a Glance

React’s Server‑Side Rendering prerenders an entire route to HTML on the server, then hydrates it in the browser—trading server CPU for faster first paint and better SEO.
React Server Components, by contrast, keep individual components on the server; they stream a lightweight Flight payload that stitches server‑rendered fragments into an otherwise client‑side tree without shipping those components’ JavaScript.

Because scope and output differ—HTML page vs. per‑component Flight stream—SSR and RSC can be used separately or in tandem.

2. Where We Came From: A Short History

2.1 Classic CSR → Early SSR

Before 2016 most React apps were pure client bundles; the first paint waited for JS download and execution. Early Next.js (≤ v12) popularised full‑page SSR with getServerSideProps, improving TTFB but still shipping the same JS twice (server + client).

2.2 The 2020 “Flight” Demo

The React core team previewed “Flight”, a streaming protocol to serialise component trees without HTML, planting the seed for RSC.

2.3 2023‑2025 Maturation

By 2025, Next.js 14 and Remix embraced RSC with segment‑level streaming and edge support, while frameworks added hybrid strategies (SSG, ISR, edge SSR).

3. Rendering Anatomy in React

Streaming SSR can send HTML chunks as soon as they’re ready, shortening Largest Contentful Paint.

4. React Server Components in Depth

4.1 What Makes Them “Components”

RSCs are first‑class React components annotated with the "use server" directive (or placed in a /server folder). They can import Node‑only libraries, make blocking DB calls, and run async/await directly without waterfalls.

4.2 The Flight Payload

Instead of HTML, the server streams a binary‑friendly text protocol nicknamed Flight—think JSON plus symbols—that instructs the client runtime how to inflate placeholders.

4.3 No Client Bundle = Slimmer JS

Because RSCs never reach the browser, bundle size drops dramatically; only interactive client components are hydrated.

4.4 Data‑Fetching Colocation

Each RSC fetches its own data, eliminating the old “load everything in getServerSideProps then prop‑drill” pattern.

5. SSR vs RSC: Head‑to‑Head Comparison

6. Real‑World Scenarios and Code Patterns

6.1 To‑Do App Revisited

Static chrome, dynamic list: Render Header, Sidebar, and Footer as RSC cached segments. The TodoList RSC queries the DB and streams each <TodoItem client /> as the user adds items—no full page refresh or JS bloat.

// app/todos/TodoList.server.jsx
export default async function TodoList() {
  const todos = await db.todo.findMany();        // runs on server only
  return (
    <ul>
      {todos.map(t => <TodoItem key={t.id} {...t} />)} {/* client component */}
    </ul>
  );
}

6.2 E‑commerce PDP

Price and inventory come from an RSC, while the photo carousel hydrates as a client component; SEO bots still receive SSR‑generated HTML wrapper for canonical markup.

7. Performance, Caching, and Streaming

Edge‑side SSR renders near users, trimming TTFB.
Segmented RSC streaming combined with Suspense lets you display skeletons, then progressively reveal data.
CDN caching of RSC payloads is safe because personal data never leaks—server encloses secrets.

8. Developer Experience & Data‑Fetching

Pros

• Ergonomic async/await inside components.
• Zero prop‑drilling: fetch where you use.
• Bundle analysis shows real KB savings when heavy libraries remain server‑only.

Cons

• Mental model split: devs must label server vs. client modules carefully.
• Tooling maturity: hot‑reloading of RSCs is still improving.

9. Orchestrating Both Techniques Together

Next.js 14’s default router renders top‑level segments as RSCs, then lets you opt‑in to client components where interactivity is needed—delivering SSR + RSC out‑of‑the‑box.

Typical flow:

1. HTTP request hits edge runtime.
2. RSC tree streams while suspended parts await data.
3. Framework wraps final HTML inside root Document for SEO.
4. Client runtime hydrates interactive leaves.

10. Framework Support in 2025

11. Migration & Refactor Playbook

1. Audit bundle size; mark heavy util libraries as server‑only.
2. Slice routes: move data‑heavy components into *.server.{js,jsx} files.
3. Introduce Suspense boundaries to preserve UX while streaming.
4. Retire getServerSideProps gradually; co‑locate queries.
5. Monitor metrics: TTFB, JS KB, and interaction latency; compare before/after.

12. Frequently Asked Questions

13. Key Takeaways & Next Steps

• Different scopes: SSR targets pages; RSC targets individual components.
• Different outputs: HTML vs. Flight.
• Use them together for fastest first paint and minimal JS.
• Start by migrating non‑interactive, data‑heavy widgets to RSC, then add streaming SSR for above‑the‑fold HTML.
• Keep measuring—React DevTools and Next.js 14 profiler panels help pinpoint hydration bottlenecks.