A hands-on benchmark built with a Node harness and a byte-counting TCP proxy measures the real wire cost of WebSocket, SSE, and long polling delivering 1,000 events. WebSocket used 119,692 bytes, SSE 131,596 (10% more), and HTTP/1.1 long polling 884,698 bytes (7.4x), mostly re-sent headers. On HTTP/2, long polling drops to 182,475 bytes (1.56x payload). Latency differences at low event rates were under 0.3ms across all three; long polling only degrades when events arrive faster than a round trip. Server memory for 500 idle connections favored WebSocket (6.2-6.7MB) over SSE (11MB) and long polling (10.3-10.9MB). Practical failure modes covered include idle timeouts, proxy buffering, and the six-connections-per-origin HTTP/1.1 cap on SSE. The recommendation: build SSE first for server-to-client feeds, move to WebSocket only when upstream or binary data is needed.
Table of contents
What does each transport cost on the wire?Does HTTP/2 fix long polling?Is WebSocket actually faster per message?What does a connection cost the server?When is SSE enough?What breaks these in production?Which one should you actually pick?How I measured thisFAQThe part worth rememberingQuestions this post answers
How many bytes does long polling actually cost compared to WebSocket for delivering the same events?
Long polling over HTTP/1.1 with keep-alive costs 884,698 bytes to deliver 1,000 events versus 119,692 bytes over a WebSocket, a 7.4x difference, mostly from HTTP headers re-sent on every request. Moving long polling to HTTP/2 cuts that to 182,475 bytes (1.56x payload) because HPACK compresses repeated headers after the first request. Weigh these transport tradeoffs against your own event rate using benchmarks like this one on daily.dev.
Is SSE actually slower than WebSocket for real-time delivery?
No, per-message delivery latency is essentially identical. In simulated tests over a 50ms round trip, SSE delivered events in 26.29-26.52ms mean while WebSocket delivered in 26.16-26.46ms, a gap under half a millisecond. SSE costs about 10% more bytes on the wire, but that doesn't translate into a noticeable latency penalty. Developers comparing SSE and WebSocket for latency-sensitive features can track findings like this on daily.dev.
Why does my SSE connection keep dying after about 60 seconds?
An idle timeout on a load balancer or proxy is closing the connection. AWS Application Load Balancer defaults to a 60-second idle timeout when no data is sent in either direction, and Cloudflare closes idle WebSocket connections similarly. Send a comment line like ':heartbeat\n\n' every 15 seconds or so, since the SSE spec designed comment lines specifically to be ignored by the client while keeping the connection alive. Debugging dropped SSE connections in production gets easier by following real-world fixes shared on daily.dev.
1.2M Impressions29 Comments
1 Award
1 Award