WebSocket send buffers without backpressure, so bufferedAmount is the only flow control signal

ws.send() returns immediately and queues the data inside the browser regardless of how fast the network drains it. A producer that outruns the connection grows that queue until the tab runs out of memory, and nothing in the API pushes back. ws.bufferedAmount reports the bytes still queued and is the only way to notice, so check it before sending and skip, coalesce or drop when it exceeds a threshold you choose.

The value counts bytes not yet handed to the network, so it does not fall to zero the instant the peer receives them, and it excludes protocol framing overhead. Calling close() while data is buffered still delivers what is queued before the close frame. For genuinely streaming workloads the WebSocketStream API applies real backpressure through streams, but it remains Chromium-only, so a manual bufferedAmount check stays the portable answer.