Understanding Streaming in React 19
Learn how React streaming works at the renderer level, how React incrementally commits UI as it becomes ready, without blocking on slower parts of the tree.
Modern applications rarely resolve all data and UI dependencies at once. Some parts of a page are commit-critical for orientation and can render immediately, while others depend on slower computations, large datasets, or remote services. If we treat the entire screen as a single blocking unit, users end up waiting for the slowest piece, even though most of the UI is already usable, leading to delayed first impressions and overreliance on full-page loading states.
A common misconception is that “streaming” just means splitting the UI into lots of fragments or showing more spinners. In React, streaming is fundamentally about commit strategy: React can reveal UI in stages when it’s safe, keeping already-committed regions stable while slower parts load behind their own boundaries. Without streaming, developers often compensate by manually orchestrating loading flags and conditional renders across the app. With streaming, React handles progressive reveal at the renderer level, committing ready subtrees as soon as they’re available while the rest continues rendering in the background.
How React Streaming works: Rendering vs commit
Streaming is a renderer capability that lets React commit UI in stages instead of waiting for the entire tree to finish rendering. That means users can see and interact with the parts that are ready while slower regions continue to load.
This is possible because React separates render from commit: render computes the next UI, and commit applies it to the host environment (like the DOM). With streaming, React can commit any completed region that isn’t blocked by unresolved data.
Suspense boundaries define where streaming can pause. If a subtree suspends by throwing a Promise, React can still commit everything outside that boundary and show a fallback (or withhold that region). When the data resolves, React retries the suspended subtree and commits the real UI later without disturbing what’s already on screen. Crucially, each streamed update is still a safe, consistent UI state: React never commits partial components, only complete results.
While true streaming over the network happens during server rendering, the same commit semantics apply on the client; this example focuses on the commit model, not transport.
Let’s visualize how React progressively renders and commits different parts of the UI ...