A React Server Components render produces a serialized RSC payload in addition to HTML, and that payload is streamed too. How does a <Suspense> boundary shape it, and why does that matter for a client-side navigation where no new HTML document is fetched?

## Two outputs from one server render A Server Components render does not only produce HTML. It produces a serialized description of the rendered server tree, commonly called the RSC payload, which the React client runtime knows how to read. On an initial page load both are produced: HTML so the browser has something to paint and hydrate, and the payload so the client runtime knows the *component-level* structure — including which parts are client components and what props they were given. The payload is deliberately not HTML. It represents: - rendered server output as element data (type, props, children) rather than markup; - **client components as references** — a pointer that the client resolves against its bundle to load and render the real component; - serializable props crossing the boundary; and - **pending regions as placeholders** whose real content is appended later. That last point is the streaming one. ## How a boundary shapes the payload The payload is written as a sequence of rows over an open stream, not assembled and sent at the end. When the server render reaches a component that suspends inside a `<Suspense>` boundary, it does not stall the serializer: it writes a row for the boundary that references a chunk not yet available, and carries on serializing the rest of the tree. When the suspended data settles, the server appends the rows for that subtree, keyed so the client can attach them to the reference it already read. Structurally this is the same idea as the HTML side — a boundary is a legal place to cut the output — but the delivery differs. In HTML the late chunk is a hidden container plus an inline script that performs a DOM move. In the payload the late rows are just more data on the stream, and the client runtime re-renders that boundary with the resolved content once they arrive. ## Why it matters for client navigation On the first load, both mechanisms are in play. On a client-side navigation, only one is: the browser stays on the same document, so no HTML is fetched. The router requests the RSC payload for the destination route, and React applies the incoming tree to the running application, preserving client component state where the tree structure allows. Because the payload is streamed, the destination screen does not have to arrive all at once. Everything outside pending boundaries can render as soon as its rows land; everything inside a still-pending boundary shows its fallback until its rows are appended. Without boundaries, the navigation waits for the whole payload — meaning the slowest server data on the destination route gates the entire screen change, which users experience as a frozen click. ```jsx // same boundary serves both transports <Suspense fallback={<ReviewsSkeleton />}> <Reviews productId={id} /> {/* server component, slow query */} </Suspense> ``` On first load this is a fallback in the HTML shell plus a later HTML chunk. On a client navigation to the same route it is a fallback rendered from a placeholder row plus later payload rows. You wrote one boundary; it bought you incremental delivery on both paths. ## Consequences worth naming - **Serialization constrains what can stream.** Only serializable values cross into the payload; functions and class instances cannot, and a client component's props must survive the serializer. A slow subtree that cannot be serialized cannot be deferred as payload rows either. - **Client state survives, boundaries repaint.** Applying a new payload to the existing tree is a React update, not a document replacement, so client component state outside the changed regions is preserved — one of the main reasons navigation uses the payload rather than fetching HTML. - **A boundary is the unit of partial arrival on both paths.** If you audit a route for streaming behaviour, the same audit answers "what does the user see mid-navigation" — there is one answer, not two. - **Errors after the first rows are committed** behave like the HTML case: you cannot retroactively turn the response into an error status, so recovery is expressed in the tree via boundaries rather than in the transport. ## What not to claim Be careful to keep this at the React level. The specific wire format, the row syntax, and how a framework caches or revalidates payloads are implementation and framework territory — a strong answer describes the *model* (streamed rows, references for client components, placeholders for pending subtrees) without inventing syntax. Likewise, do not describe the payload as "HTML for the client" or as JSON you can hand-write; it is a React-specific serialization consumed by the React runtime, and its value is precisely that it preserves component identity rather than flattening to markup.