SYSTEM Cited by 1 source

React Flight

React Flight (github.com/facebook/react) is the name of React's wire protocol and streaming serialiser for React Server Components (RSC). It encodes server-rendered output + component payloads as a sequence of byte chunks flowing over a byte-oriented ReadableStream, to be deserialised and hydrated on the client.

The byte-stream pattern

Flight emits output through the specific Web Streams shape:

const stream = new ReadableStream({
  type: 'bytes',
  start(ctrl) { controller = ctrl; }
});
// later, as the render produces output:
controller.enqueue(new Uint8Array(payload1));
controller.enqueue(new Uint8Array(payload2));

Three distinguishing features:

• type: 'bytes' — byte-oriented stream (not the default value-oriented). Allows the controller to coalesce small enqueues into larger reads.
• Controller captured in start() — external code retains the controller reference and enqueues asynchronously as rendering produces chunks.
• Hundreds of streams per request — under production load, a single request path constructs many of these.

Why it's the benchmark extremum

Vercel's 2026-04-21 disclosure measured this exact pattern at ~110 MB/s on native Node.js Web Streams versus ~1,600 MB/s on fast-webstreams — a 14.6× gap, the largest of any measured workload. Canonical quote:

"This is the one that matters most for Next.js. React Server Components use a specific byte stream pattern… Native WebStreams: ~110 MB/s. fast-webstreams: ~1,600 MB/s. That is 14.6x faster for the exact pattern used in production server rendering."

The overhead concentration is two-fold: 1. Per-construction cost — the full ReadableStream + Readable init is heavy when hundreds are created per request. Fast-webstreams backs these with LiteReadable for a ~5 µs per-construction saving. 2. Per-chunk allocation — each controller.enqueue → downstream read() round-trip allocates read requests, Promises, and {value, done} results (see concepts/promise-allocation-overhead).

Role in streaming SSR

React Flight is the transport layer under Next.js App Router's streaming SSR. The Flight stream carries both initial HTML and server component payloads; the browser receives the stream via fetch() response body, deserialises it, and hydrates.

Canonical empirical finding across vendors (concepts/web-streams-as-ssr-bottleneck): the stream layer — not the React reconciler — is the dominant CPU cost for Flight rendering under Node.js.

Historical note

• 2023: Flight introduced via RSC experimental in React 18 alpha.
• 2024: Next.js 13 / 14 App Router ships Flight as the default RSC transport.
• 2025-10-14 (Cloudflare): profiling of OpenNext + Next.js + Flight surfaces buffer allocation in pipeThrough as a GC pressure source.
• 2026-04-21 (Vercel): fast-webstreams measures Flight byte-stream pattern at 14.6× over native Web Streams; builds LiteReadable specifically to serve it.

Seen in

• sources/2026-04-21-vercel-we-ralph-wiggumed-webstreams-to-make-them-10x-faster — canonical wiki instance of React Flight as the specific Web-Streams benchmark extremum. The byte-stream + external-enqueue pattern is the shape where the fast/native gap is largest (14.6×). Drives the LiteReadable design decision inside fast-webstreams.

Related

• systems/react — the framework Flight is part of.
• systems/nextjs — the framework that streams Flight payloads at production scale.
• systems/web-streams-api — the underlying stream API.
• systems/fast-webstreams — the Vercel library whose largest measured win lands here.
• systems/lite-readable — the custom Readable replacement designed to serve this workload.
• concepts/streaming-ssr — the use case.
• concepts/web-streams-as-ssr-bottleneck — the profiling-surfaced bottleneck category.
• concepts/promise-allocation-overhead — the dominant cost class inside Flight's transport.