WebSocket vs SSE vs long-polling: choosing the right transport

Before you reach for WebSocket, ask whether you actually need bidirectional communication. SSE handles 90% of “server needs to push” use cases with zero custom reconnection logic and friendlier proxies. Picking the wrong transport costs you weeks of debugging or unnecessary complexity.

Three transports, three models

WebSocket — full-duplex, minimal overhead

After the upgrade handshake, either side sends frames at any time. Per-message overhead is 2–6 bytes. The server can push without the client asking; the client can push without a new HTTP connection. This is the right choice when:

• The client sends data frequently (game input, collaborative editing, trading orders).
• Latency budget is under 10 ms.
• You control the proxy/infrastructure (or know it supports Upgrade).

Downside: no built-in reconnection. If the connection drops (proxy idle timeout, network glitch), your code must detect close code 1006 and reconnect with backoff.

SSE — server push, browser handles everything

SSE uses a normal persistent HTTP response with Content-Type: text/event-stream. The server writes newline-delimited events:

event: price-update
data: {"symbol":"AAPL","price":182.34}
id: 4291

The browser’s native EventSource API parses events and automatically reconnects using the Last-Event-ID header if the connection drops. Latency is 3–8 ms. Zero reconnection code to write. Works through any HTTP/1.1 proxy including corporate firewalls.

SSE is wrong when:

• The client needs to send data (you need a separate REST endpoint for that, which is awkward).
• You need binary payloads (SSE is text-only).

Long-polling — the universal fallback

The client opens an HTTP request and the server holds it open until data arrives (or a timeout fires). When the server responds, the client immediately opens a new request. This simulates server push using only standard HTTP.

Latency = the time the server holds the request + one RTT. At best, 100 ms for a server that answers immediately. At worst, 60+ seconds for a server with a long timeout before giving up and responding empty.

Overhead is high: every poll carries full HTTP headers (~500+ bytes). At 50,000 clients polling every 100 ms, that is 500,000 HTTP requests/second. Essentially no modern application uses long-polling as a primary transport — it is the graceful fallback for environments that block WebSocket.

Subprotocol and extension negotiation

The client can request an application-layer subprotocol during the upgrade:

Sec-WebSocket-Protocol: chat, superchat

The server picks one and echoes it back. Subprotocols let teams version their message format without touching the WebSocket layer — chat uses JSON messages, superchat uses a compact binary format. If the server sends no subprotocol header, the connection has no named protocol (still valid; the application defines the message format implicitly).

Extensions work similarly via Sec-WebSocket-Extensions. The most important extension in practice is permessage-deflate (RFC 7692): DEFLATE compression per message. On text payloads (JSON, HTML) compression ratios of 50–90% are typical. On small messages (< 64 bytes) compression can expand the payload. On already-compressed data (images, video) it achieves nothing. The memory cost is significant: at default settings, each compressor consumes ~256 KB and each decompressor ~44 KB — at 100k idle connections, that is ~25 GB of RAM from compression state alone. Most production deployments disable permessage-deflate by default.