The RSC rendering pipeline
HTML, the RSC payload, and client JavaScript have different jobs. Once those jobs are clear, hydration and App Router navigation make much more sense.
Three pieces arrive for different reasons
- HTML gives the browser a useful initial representation.
- The RSC payload describes rendered Server Component output and references to Client Components.
- Client JavaScript provides the implementation needed to hydrate and run interactive components.
The RSC payload is not HTML
React uses a framework-managed serialized representation for Server Component output. It lets React reconcile the server-rendered tree and understand where Client Components belong.
The important consequence is architectural: a Server Component can contribute UI without its implementation becoming ordinary client-side application code.
From component tree to interactive page
Hydration is where interaction wakes up
Server-rendered HTML can be visible before every interactive component is ready. Hydration attaches React's client behaviour to the relevant markup.
This is one reason client bundle size still matters in a server-first application. Unnecessary client boundaries mean more code to download, parse, execute, and hydrate.
Can you explain “The RSC rendering pipeline” without reaching for the API reference?
Describe the main trade-off, one failure mode, and the decision you would make in a real project.