Add Flight SSR benchmark fixture (#36180)

This PR adds a benchmark fixture for measuring the performance overhead
of the React Server Components (RSC) Flight rendering compared to plain
Fizz server-side rendering.

### Motivation

Performance discussions around RSC (e.g. #36143, #35125) have
highlighted the need for reproducible benchmarks that accurately measure
the cost that Flight adds on top of Fizz. This fixture provides multiple
benchmark modes that can be used to track performance improvements
across commits, compare Node vs Edge (web streams) overhead, and
identify bottlenecks in Flight serialization and deserialization.

### What it measures

The benchmark renders a dashboard app with ~25 components (16 client
components), 200 product rows with nested data (~325KB Flight payload),
and ~250 Suspense boundaries in the async variant. It compares 8 render
variants: Fizz-only and Flight+Fizz, across Node and Edge stream APIs,
with both synchronous and asynchronous apps.

### Benchmark modes

- **`yarn bench`** runs a sequential in-process benchmark with realistic
Flight script injection (tee + `TransformStream`/`Transform` buffered
injection), matching what real frameworks do when inlining the RSC
payload into the HTML response for hydration.
- **`yarn bench:bare`** runs the same benchmark without script
injection, isolating the React-internal rendering cost. This is best for
tracking changes to Flight serialization or Fizz rendering.
- **`yarn bench:server`** starts an HTTP server and uses `autocannon` to
measure real req/s at `c=1` and `c=10`. The `c=1` results provide a
clean signal for tracking React-internal changes, while `c=10` reflects
throughput under concurrent load.
- **`yarn bench:concurrent`** runs an in-process concurrent benchmark
with 50 in-flight renders via `Promise.all`, measuring throughput
without HTTP overhead.
- **`yarn bench:profile`** collects CPU profiles via the V8 inspector
and reports the top functions by self-time along with GC pause data.
- **`yarn start`** starts the HTTP server for manual browser testing.
Appending `.rsc` to any Flight URL serves the raw Flight payload.

### Key findings during development

On Node 22, the Flight+Fizz overhead compared to Fizz-only rendering is
roughly:

- **Without script injection** (`bench:bare`): ~2.2x for sync, ~1.3x for
async
- **With script injection** (`bench:server`, c=1): ~2.9x for sync, ~1.8x
for async
- **Edge vs Node** adds another ~30% for sync and ~10% for async, driven
by the stream plumbing for script injection (tee + `TransformStream`
buffering)

The async variant better represents real-world applications where server
components fetch data asynchronously. Its lower overhead reflects the
fact that Flight serialization and Fizz rendering can overlap with I/O
wait times, making the added Flight cost a smaller fraction of total
request time.

The benchmark also revealed that the Edge vs Node gap is negligible for
Fizz-only rendering (~1-2%) but grows to ~15% for Flight+Fizz sync even
without script injection. With script injection (tee + `TransformStream`
buffering), the gap roughly doubles to ~30% for sync. The async variants
show smaller gaps (~5% without, ~10% with injection).

Author: unstubbable

fixtures/flight-ssr-bench/README.md

@@ -0,0 +1,62 @@
+# Flight SSR Benchmark
+
+Measures the performance overhead of the React Server Components (RSC) Flight pipeline compared to plain Fizz server-side rendering, across both Node and Edge (web streams) APIs.
+
+## Prerequisites
+
+Build React from the repo root first:
+
+```sh
+yarn build-for-flight-prod
+```
+
+Then install the fixture's dependencies:
+
+```sh
+cd fixtures/flight-ssr-bench
+yarn install
+```
+
+## Scripts
+
+| Script | Purpose |
+| --- | --- |
+| `yarn bench` | Sequential benchmark with Flight script injection (realistic framework pipeline). Best for measuring Edge vs Node overhead. |
+| `yarn bench:bare` | Sequential benchmark without script injection. Best for measuring React-internal changes (e.g. Flight serialization optimizations) with less noise from stream plumbing. |
+| `yarn bench:server` | HTTP server benchmark using autocannon at c=1 and c=10. Best for measuring real-world req/s. The c=1 results are also useful for tracking React-internal changes. |
+| `yarn bench:concurrent` | In-process concurrent benchmark (50 in-flight renders). Measures throughput under load without HTTP overhead. |
+| `yarn bench:profile` | CPU profiling via V8 inspector. Saves `.cpuprofile` files to `build/profiles/`. |
+| `yarn start` | Starts the HTTP server for manual browser testing at `http://localhost:3001`. Append `.rsc` to any Flight URL to see the raw Flight payload. |
+
+## What it measures
+
+Each script benchmarks 8 render variants:
+
+- **Fizz (Node, sync/async)** -- plain `renderToPipeableStream`, no RSC
+- **Fizz (Edge, sync/async)** -- plain `renderToReadableStream`, no RSC
+- **Flight + Fizz (Node, sync/async)** -- full RSC pipeline: Flight server (`renderToPipeableStream`) -> Flight client (`createFromNodeStream`) -> Fizz (`renderToPipeableStream`)
+- **Flight + Fizz (Edge, sync/async)** -- full RSC pipeline: Flight server (`renderToReadableStream`) -> Flight client (`createFromReadableStream`) -> Fizz (`renderToReadableStream`)
+
+The "sync" variants use a fully synchronous app (no Suspense boundaries). The "async" variants use per-row async components with staggered delays and individual Suspense boundaries (~250 boundaries per render).
+
+### Script injection
+
+The `yarn bench` and `yarn bench:server` scripts simulate what real frameworks do: tee the Flight stream and inject `<script>` hydration tags into the HTML output. This uses a `setTimeout(0)`-buffered Transform/TransformStream to avoid splitting mid-HTML-tag. `yarn bench:bare` skips this for cleaner React-internal measurement.
+
+## Test app
+
+A dashboard with ~25 components (16 client components), rendering:
+
+- 200 product rows with nested reviews, specifications, and supplier data (~325KB Flight payload)
+- 50 activity feed items
+- Stats grid with 24-month chart data
+- Sidebar with navigation and recent activity
+
+## Output
+
+The overhead tables show two comparisons:
+
+1. **Flight overhead** -- Flight+Fizz vs Fizz-only (how much RSC adds)
+2. **Edge vs Node** -- web streams vs Node streams (stream implementation cost)
+
+Delta is shown as percentage change plus a factor (e.g. `+120% 2.20x` means 2.2x slower).