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 · server → browser

The data flow, visualised.

Each box is a stage in execution order. Arrows are handoffs — the artifact one stage produces is the next stage's input. The right-hand bar shows each stage's relative contribution to client JavaScript: notice the server stages ship none. Click any stage for the full breakdown; hover the dotted terms for definitions.

SERVER SERIALIZE STREAM BROWSER HYDRATE INTERACT STAGE 01 Request & route match url → matched route client JS · 0/100 STAGE 02 Server Components render await db · fs · secrets client JS · 0/100 STAGE 03 RSC render → Flight payload tree → serialized rows client JS · 4/100 STAGE 04 SSR: HTML from Flight react-dom → streamed HTML client JS · 4/100 STAGE 05 Streamed response HTML + Flight, one trip client JS · 6/100 STAGE 06 Parse & paint → FCP DOM · CSSOM · first paint client JS · 6/100 STAGE 07 Load chunks & read Flight $L → import() client code client JS · 72/100 STAGE 08 Reconstruct tree & hydrateRoot attach listeners → TTI client JS · 96/100 STAGE 09 Server Actions & navigation POST action · fetch route client JS · 42/100

Tip — press Esc to close any panel · click a stage to dive in and ▶ play its live demo · the bar is relative client JS, not time

Reference · 9 stages

Every stage, in depth.

The same stages as cards. Each opens a structured breakdown that now leads with an interactive demo — press play to watch the handoff step by step — followed by 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

Stage 5 streams HTML and the Flight payload together in a single HTTP response. Suspense boundaries flush a fallback first, then stream their resolved content in-band — no second round trip.

Browser

Paint → hydrate

Stages 6–9 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