Edge Rendering & Server Components: SSR Hydration, Static Regeneration (ISR), and React Server Components

A high-traffic news platform migrated its entire application from static HTML to dynamic Server-Side Rendering (SSR). They expected improved search rankings and faster page loads.

Instead, their database CPU spiked to 100%, and Time to First Byte (TTFB) degraded from 40ms to 1.8 seconds.

Because every HTTP request forced the SSR Node.js server to query five backend databases and execute CPU-heavy React render calls before returning the first byte of HTML, the server queue backed up during peak traffic spikes. Worse, once the HTML finally reached the browser, client devices had to download a 1.4MB JavaScript bundle to hydrate components—causing layout shifts and input latency.

The pendulum of web rendering architecture has swung from PHP/Java server templates to fully client-rendered SPAs, and now to hybrid Edge Rendering and React Server Components (RSC).

---

1. Rendering Taxonomy Comparison

+-----------------------------------------------------------------------------------------+
|                                Rendering Architecture Spectrum                          |
+---------------------+-------------------+-------------------+---------------------------+
| Strategy            | HTML Generation   | First Load (TTFB) | Interactive Speed (INP)   |
+---------------------+-------------------+-------------------+---------------------------+
| CSR (Client)        | Browser JS        | Fast TTFB         | Slow (Must fetch JS bundle)|
| SSR (Server)        | Server Per-Req    | Medium TTFB       | Medium (Requires Hydration)|
| SSG (Static)        | Build-Time        | Fast TTFB (CDN)   | Fast                      |
| ISR (Incremental)   | Static + Revalidate| Fast TTFB (CDN)  | Fast                      |
| RSC (Server Comp)   | Server Stream     | Fast TTFB (Edge)  | Fast (Zero Client JS Bundle)|
+---------------------+-------------------+-------------------+---------------------------+

---

2. React Server Components (RSC) Architecture

React Server Components (RSC) split React components into two distinct operational categories:

1. Server Components: Execute exclusively on the server (or Edge worker). Their code is never included in the JavaScript bundle downloaded by the browser. They can access backend databases, file systems, and internal microservices directly.
2. Client Components: Standard interactive React components annotated with "use client". They are sent to the browser and hydrated normally.

[ Request ] ---> [ Server / Edge Worker ]
                        |
            Executes Server Components (RSC)
            Direct Database / microservice calls
                        |
            Serializes RSC Flight Payload Stream
                        v
[ Browser Client ] <--- Streams JSON-like RSC Tree + Hydrates Client Components

The RSC Flight Payload Stream Format

Unlike traditional SSR which serializes components into plain HTML strings, React Server Components serialize the UI tree into a special binary/JSON stream format known as the RSC Flight Payload:

M1:{"id":"/src/ClientButton.js","name":"default","chunks":["client0"]}
J0:["$","div",null,{"children":[["$","h1",null,{"children":"Server Dashboard"}],["$","$L1",null,{"label":"Click Me"}]]}]

• Zero Bundle Impact: Heavy dependencies (e.g., marked markdown parser, date-fns) used inside Server Components remain on the server, saving megabytes of client JavaScript.
• Direct Database Access:

// Server Component (src/app/Dashboard.tsx) - EXECUTED EXCLUSIVELY ON SERVER!
import db from "@/lib/db"; // Internal DB driver never leaks to client!
import { ClientAnalyticsButton } from "./ClientAnalyticsButton"; // Client Component

export async function Dashboard({ userId }: { userId: string }) {
  // Direct SQL Query inside React Component!
  const user = await db.query("SELECT name, role FROM users WHERE id = $1", [userId]);

  return (
    <div className="dashboard">
      <h1>Welcome back, {user.name}</h1>
      <p>Role: {user.role}</p>
      {/* Interactivity isolated to explicit Client Component boundary */}
      <ClientAnalyticsButton userId={userId} />
    </div>
  );
}

---

3. Edge Rendering & Streaming HTML Responses

Traditionally, SSR servers generate the entire HTML document string before returning a response to the browser. If a database query takes 1.5 seconds, the browser receives 0 bytes until the full page renders (High TTFB).

Edge Rendering with HTTP Streaming uses ReadableStream to stream the HTML <head> and shell structure immediately, using React <Suspense> boundaries to stream fallback placeholders and lazy-render slow data chunks as they resolve.

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked

Chunk 1: <html><head>...</head><body><div id="shell">Header...</div>
Chunk 2: <div id="suspense-fallback">Loading Dashboard...</div>
Chunk 3 (1.2s later): <template id="dashboard-data">...actual data...</template><script>replaceSuspense()</script>

---

Summary & Key Takeaways

• CSR vs SSR vs ISR: CSR offloads rendering to the browser; SSR computes HTML per request; SSG/ISR caches static HTML pages at CDN edge nodes with background revalidation.
• React Server Components (RSC): Component-level server execution that keeps heavy dependencies off client devices while permitting direct backend database queries.
• RSC Flight Stream: Serializes UI tree trees into a specialized payload stream, preserving Client Component state across navigation transitions without full-page reloads.
• Edge HTML Streaming: Uses HTTP chunked transfer encoding and React <Suspense> to stream shell markup immediately, drastically reducing Time to First Byte (TTFB).

---

References & Further Reading

1. React Core Team. React Server Components Specification & RFC. React RFCs.
2. Vercel / Next.js. Next.js App Router & Server Components Architecture. Next.js Docs.
3. Cloudflare. Cloudflare Workers & V8 Edge Runtime Specifications. Cloudflare Docs.

---