When we started profiling Next.js server rendering earlier this year, one thing kept showing up in the flamegraphs: WebStreams. Not the application code running inside them, but the streams themselves. The Promise chains, the per-chunk object allocations, the microtask queue hops. After highlighted how much compute time goes into framework overhead, we started looking at where that time actually goes. A lot of it was in streams.Theo Browne's server rendering benchmarks Turns out that WebStreams have an , and that makes them a great candidate for doing an AI-based re-implementation in a purely test-driven and benchmark-driven fashion.

This post is about the performance work we did, what we learned, and how this work is already making its way into Node.js itself through Matteo Collina's .incredibly complete test suiteupstream PR Node.js has two streaming APIs. The older one (, , ) has been around for over a decade and is heavily optimized. Data moves through C++ internals. Backpressure is a boolean. Piping is a single function call.stream.Readablestream.Writablestream.Transform The newer one is the WHATWG Streams API: , , . This is the web standard. It powers response bodies…