AI Features

Understanding the RSC Rendering Pipeline

Learn how React Server Components (RSC) move through a multi-stage rendering pipeline and how React 19 coordinates data, rendering, and commits across server and client without treating the UI as a single blocking task.

React teams often encounter performance debugging issues as applications grow. Pages become slow, but it is unclear which part of the system is responsible. A route transition might show a blank gap, a loading spinner, or a skeleton, yet those visuals do not explain whether we are waiting on data, waiting on code, or waiting because rendering is blocked by a single slow region. The common mistake is treating rendering as a single step, something that either finishes or does not, when the real work involves multiple phases with distinct bottlenecks.

That collapsed mental model creates predictable pain. A slow query can delay the whole screen even though only one section depends on it. Nested data needs can form waterfalls that force sequential waiting. Loading states flicker because the UI is rebuilt around late-arriving data rather than being committed in stable stages. As complexity increases, we add more flags, more spinners, and more memoization, but we still lack a clear answer to the core question: what is React waiting for, and what could it have shown already?

React 19’s Server Component rendering pipeline exists to make that question answerable. It formalizes rendering as a staged process where some work can be completed and delivered while other work is still in flight. The goal is not just speed; it is predictable progress. The UI should stay oriented: frame first, details later, without requiring us to manually coordinate every loading state and transition.

React 19 rendering is staged: Commit what is eligible now, and stream the rest when it becomes eligible.
React 19 rendering is staged: Commit what is eligible now, and stream the rest when it becomes eligible.

The above diagram shows a top-down pipeline. A request enters the server, where React traverses the component tree. Some Server Components resolve immediately, while others suspend. Suspense boundaries appear as explicit “pause zones” around slow regions. As each region becomes ready, React streams its output in chunks to the client, filling in a stable UI frame first and details afterward. On the client side, hydration of Client Components occurs later, enabling interactivity once the necessary code is loaded, without forcing a full page rerender.

In the pipeline, hydration is selective. React 19 doesn’t wait for the entire page to load before it starts hydrating Client Components. If the client Component is ready and its code has loaded, React can hydrate it while the Activity region is still a server-side loading skeleton.

Eligibility-based rendering and incremental streaming

The Server Component rendering pipeline is a flow of eligibility rather than a single render pass. When a request begins, React starts walking the component tree and producing output as soon as regions are eligible. ...