The transport is not the bottleneck

100 clients × 30 rounds, TLS throughout. Measured client-side: from dispatch() to the patch carrying that command's nonce arriving on the client's own stream.

Each group below sits on a dashed line marking the network round trip itself — the floor no architecture can beat. Every bar is essentially that floor plus a couple of milliseconds.

The handshake claim, isolated

The interesting column is the first command after connect — the moment an HTTP/1.1 client has to open a fresh socket, and exactly the cost the article is pointing at.

Counted below TLS at the proxy, per command round trip, after connect — so this is marginal steady-state cost, not first paint.

For a single 500-byte row, WebSocket wins by 92 bytes. Nobody will notice. But send a whole-board morph — the pattern that makes HTML-over-the-wire pleasant to write — and the result reverses hard.

Three structural reasons, none of them tunable on the WebSocket side.

a. There is no brotli for WebSocket

permessage-deflate (RFC 7692) is the only compression extension the protocol defines, and it negotiates exactly one codec: DEFLATE. An SSE stream is an ordinary HTTP response, so Content-Encoding: br simply applies — and every browser has decoded it in the network stack since 2016.

b. DEFLATE's window is capped at 32 KB by the format

This is the mechanism. For patch N to compress against patch N−1, the previous copy must still be inside the sliding window. Sweep the window against an 86.3 KB board and the failure is a cliff, not a slope:

The real threshold is half the window

A live version of this — two chat panes on one server, one over each transport — sharpens the number. To compress copy N against copy N−1, the window has to hold both. So DEFLATE's usable payload ceiling is about 16 KB, not 32 KB. Growing a chat log and watching cost per patch shows exactly where it breaks:

c. Context takeover is a memory bill proxies refuse to pay

Keeping the zlib dictionary alive between messages is what gets WebSocket to even 22×. Without it the narrow-patch case collapses from 10.0× to 1.8×. It costs roughly 256 KB per connection, so servers and proxies routinely negotiate no_context_takeover to bound memory — silently halving your ratio.

Brotli is 48× smaller and 3× cheaper to encode than the best a WebSocket can do — cheaper because once the dictionary is warm it emits back-references instead of doing fresh Huffman work.

A WebSocket is one ordered byte stream, so commands apply in send order for free. Splitting reads from writes gives that up — the question is how much it actually costs.

Bursts of 10 un-awaited commands. HTTP/2 preserved order in every trial — concurrent POSTs multiplex onto one ordered TCP connection, so they reach the server in send order. HTTP/1.1's 5-socket pool reordered 2.11% of pairs, which is a genuine hazard if your commands don't commute.

The ack→patch race is real but sub-millisecond: the POST's 204 lands ~0.14ms before the patch it caused, so code that re-enables a button on POST success runs just before the DOM updates. Drive UI off the patch, not the ack.

The argument that needs no benchmark. Both architectures need the same subscriber registry — the claim that WebSockets need one and SSE doesn't is simply false, and in this codebase that registry is shared verbatim.

What differs is what the write path has to touch:

// SSE + CQRS — the command handler has no transport in it at all.
function handleCommand(room, id, nonce) {
  const row = apply(board, { id, nonce })
  return broadcast(room, () => sseEvent(renderPatch(board, row, MODE)))
}

handleCommand is a pure function of (room, id, nonce). It's callable from an HTTP route, a cron job, a webhook, a queue consumer, or another user's request, and it never sees a socket. The WebSocket equivalent is a closure inside wss.on('connection'), structurally scoped to one socket — so dispatching from anywhere else means reaching back through the registry anyway. At which point you've re-derived the CQRS split with extra steps.

Last-Event-ID deserves emphasis: SSE resume is a browser built-in and a server-side one-liner. Every WebSocket app that cares about messages missed during a reconnect writes that machinery by hand, and most write it wrong.

Brotli's ratio isn't free — the codec context lives per connection. 2,000 idle connections, measured as RSS delta.

Compression itself is the 5–10× memory multiplier, not the choice of window — and it isn't a WebSocket-vs-SSE axis at all: ws deflate and sse gzip are the same zlib bill (430 vs 458 KB).

So the honest shape of the trade: fat morphs plus brotli buys a 48× byte reduction at roughly 10× the per-connection memory. Excellent for a few thousand concurrent editors; bad for 50k idle viewers. Above that scale you send narrow patches, drop to gzip, or terminate compression at an edge tier instead of in the origin process.