WebTransport Is Not a Faster WebSocket

At FOSDEM 2026, Max Inden walked through WebTransport as the thing people keep calling the next WebSocket. The InfoQ write-up of that talk is useful because it refuses the slogan. WebSocket gives you one reliable, ordered, bidirectional stream of messages. WebTransport, over HTTP/3 and QUIC, gives you many reliable streams plus unreliable datagrams, on one connection, with a handshake that can finish in a single round trip. Those are different products. Treating the second as a faster version of the first is how a market-data port wastes a quarter.

The failure mode WebSocket cannot escape is head-of-line blocking. TCP delivers bytes in order. If one packet is lost, everything behind it waits, including messages that had nothing to do with the lost one. A conflatable quote and a halt are not the same kind of fact, but on a single WebSocket they share a fate. QUIC streams do not. A loss on the quote lane does not freeze the control lane. Datagrams go further: they may be lost, reordered, or skipped, which is the correct failure mode for a price that will be replaced in 50 milliseconds.

The port that throws the win away

The common mistake, and the one streaming engineers keep writing up in 2026, is to move an existing WebSocket protocol onto a single WebTransport bidirectional stream and call it done. You have built WebSocket-over-QUIC. You still have one ordered pipe. You paid for HTTP/3 complexity and left independent streams and datagrams on the table.

A quote fan-out that actually uses the API looks like three lanes, not one:

• Datagrams for top-of-book updates that are safe to conflate. The newest price wins. Retransmitting a stale tick spends bandwidth to be wrong on purpose.
• A reliable stream for trades, halts, corrections, and anything a subscriber must not miss. Loss here is a defect, not a feature.
• A separate reliable stream for session control: subscribe, unsubscribe, auth refresh, heartbeats. A burst of quotes must not sit in front of a resubscribe after a network change.

Same QUIC connection. Different reliability. The browser API is explicit that these are not interchangeable with WebSocket.send. If your SDK still exposes only onmessage, you have not ported the protocol. You have tunneled it.

Where WebSocket stays the default

None of this retires the WebSocket protocol for the workloads it fits. A moderate fan-out, a chatty control channel, intermediaries that already speak WebSocket, and mobile stacks with a decade of reconnect libraries are still better served by the boring socket. MQTT and SSE sit next to it in our public protocol table for the same reason: the right pipe is the one the subscriber can operate at 2 a.m. A simple stream of a few messages a second does not earn QUIC's deployment cost.

WebSocket's real tax is elsewhere. It has no message-level credit the way HTTP/2 or QUIC flow control does. A slow consumer buffers in the socket, and the browser's bufferedAmount is only a coarse hint. You will still write backpressure yourself. WebTransport gives you QUIC's flow control, which stops a sender from overflowing a connection. It does not decide that a quote is stale. That policy stays in the application: drop conflatable updates, keep trades, tell the client it fell behind.

Handshake math is the other half of the FOSDEM pitch. A cold WebSocket is TCP, then TLS, then an HTTP upgrade, multiple round trips before the first frame. WebTransport merges the transport and cryptographic handshake into one RTT, and QUIC 0-RTT resumption can send data immediately for a returning session. On a phone with a 40ms round trip, setup alone can spend a 100ms tick-to-glass budget before a byte of market data arrives. Cutting setup to one RTT is worth more than shaving a millisecond off your normalize step.

0-RTT is not for everything

Zero round trips is a replay window. An idempotent "send me the latest quote for this symbol" can ride 0-RTT. A subscribe that mutates server-side interest, or anything that looks like an order, should not. We are a market-data path, not a broker, and we still treat 0-RTT as opt-in per message class. Connection migration, QUIC connection IDs surviving a jump from Wi-Fi to cellular, is the other feature phones actually need. Most SDKs today just reconnect and snapshot. Migration is real in the protocol and still rare in production clients. Do not promise it on a slide because the spec mentions it.

Watch a consumer, not a whiteboard

Protocol essays drift. A phone on a busy tape does not. The public consumer we point people at is Stock Picks: a paper book fed by the same class of fan-out we describe here, WebSocket today, with the latency strip you can compare to your own stopwatch. When we move a lane to datagrams, that client is where it has to feel faster under loss, not just in a loopback account. If your port cannot name which messages are allowed to disappear, you do not have WebTransport. You have a faster handshake in front of the same ordered pipe.