Runtime Reference · React Server Components · App Router

What happens between
request and interactive

One request kicks off an ordered pipeline that crosses the network once: Server Components fetch data and render on the server, React serializes the tree into the Flight payload, react-dom streams HTML from it, the browser paints, then client chunks load and hydrateRoot wires up interactivity. This is a precise tour of every stage — server to browser, in execution order.

9
pipeline stages
2
renderers (Flight · react-dom)
1
response (HTML + Flight)
0kB
JS for Server Components
Architecture · one signal, one loop

The data flow is a circuit.

A web app is one program running on two computers — a server chip and a browser chip — joined by a single wire. Follow the signal: it descends the server, crosses the wire once as one HTTP response, climbs the browser to become interactive, then loops back across the top whenever a Server Action or navigation fires. The trace thickens with the client JavaScript it carries — hairline across the server (zero kb), heaviest at hydration. Tap any node to open the stage.

SERVER trusted · data · secrets · 0 kb BROWSER interactive · owns the DOM THE NETWORK · ONE WIRE SERVER Request match route SERVER Render await db · fs SERIALIZE Serialize → Flight rows SERIALIZE SSR HTML from Flight STREAM Stream HTML + Flight BROWSER Paint FCP · 0 kb JS HYDRATE Consume import() chunks HYDRATE Hydrate attach → TTI INTERACT Interact actions · nav STREAM The Wire 1 HTTP response → ROUND-TRIP The Round-Trip ↩ action / nav

The signal runs one full request · trace weight = client JS shipped · the loop closes on the round-trip · tap a node to dive in

Reference · 11 stages

Every stage, in depth.

The same stages as cards. Each opens a structured breakdown: what it does, the precise mechanism, what flows to the next stage, the APIs involved, and the traps that bite teams in production.

Mental model · the one-liner

The whole flow, in one sentence.

If you remember nothing else: Server Components render to a serialized tree on the server, the browser paints HTML from it for free, and hydration only re-attaches the interactive parts — so you ship data, not a runtime, for everything static.

Flight payload · annotated rsc
12345678910
0:[ "$","main",null,{"children":[
  ["$","h1",null,{"children":"The Future of React"}],
  ["$","$L1",null,{"comments":[{"id":1,"body":"Great post!"}]}],
  ["$","$L2",null,{"postId":42,"onLike":"$F3"}],
  ["$","$Sreact.suspense",null,{"fallback":["$","p",null,{"children":"Loading…"}],"children":"$L5"}]
]}]
1:I{"id":"./CommentSection.js","chunks":["chunk:abc"],"name":"CommentSection"}   // client ref
2:I{"id":"./LikeButton.js","chunks":["chunk:def"],"name":"LikeButton"}
3:{"id":"likePost","bound":null}   // server action — opaque, code stays on server
5:[ "$","section",null,{"children":"…resolved comments…"}]   // $L5 streams in later
0: row id "$" element marker element type prop key inlined data $L client ref $F server action $S suspense / stream
Server

Render & serialize

Stages 1–4 run on the server: match the route, render Server Components, serialize the tree to Flight, and stream HTML from it. Your secrets and data-layer code stay here — they never ship.

Wire

One response

Stages 5–6 are the wire: Stream flushes HTML and the Flight payload together as one chunked HTTP response, and The Wire is that response in motion — interleaved bytes on a single persistent connection, with Suspense content arriving out of order and swapping into place. No second round trip.

Browser

Paint → hydrate

Stages 7–10 happen client-side: paint HTML for instant FCP, load client chunks, rebuild the tree from Flight, and hydrateRoot attaches listeners in place — interactive without re-rendering.

Back to JIT-Atlas