Polling vs Long Polling vs SSE vs WebSockets

Polling is the option that needs nothing: the client sends GET /orders/42 every *n* seconds. The cost is arithmetic — clients / interval requests per second whether or not anything changed: 10,000 clients at 5 s is 2,000 req/s of mostly 304 Not Modified, and the average notification delay is *n*/2. Polling is right when updates are rare, when the client population is small, or when the response is cacheable at a CDN so the origin sees one request per interval rather than one per client. Over HTTP/2 the per-request overhead is small; over HTTP/1.1 each poll is a full header set, and cold connections make it worse (Keep-Alive and Connection Reuse).

Long polling flips the wait onto the server: the client sends a request and the server does not answer until there is news or a timeout (typically 20–30 s) expires, at which point the client immediately asks again. Latency drops to one RTT after the event and idle cost to one request per timeout. The costs: each waiting client holds a connection and, on a thread-per-request server, a thread; a proxy or balancer with a shorter timeout than the server’s hold time returns 504s; and HTTP/1.1 browsers spend one of their ~6 per-origin connections on the pending request. It works through every proxy and firewall on Earth, which is why it remains the fallback of choice.

SSE is an ordinary HTTP response that never ends. The client sends GET /events, the server answers 200 with Content-Type: text/event-stream, and keeps writing data: lines separated by blank lines — chunked over HTTP/1.1 (HTTP/1.1: Persistent Connections and Their Limits), a long-lived stream over HTTP/2, no upgrade, no new protocol. The browser’s EventSource API parses events, dispatches named event: types, and — the feature that makes SSE operationally pleasant — reconnects automatically after a drop, sending the last id: it saw in a Last-Event-ID header so the server can resume from where the client left off. The retry: field sets the reconnect delay.

It is one direction only: server to client. The client sends its own data with normal requests, which is fine for the majority of "push" needs (notifications, live scores, progress, log tailing, the token stream of an LLM response). SSE is text — UTF-8 only; binary must be encoded. Over HTTP/1.1 each stream occupies one of the browser’s ~6 connections per origin, which limits tabs; over HTTP/2 streams are multiplexed and the limit is the server’s stream setting, so SSE and HTTP/2 are a natural pair (HTTP/2: Streams on One Connection).

Infrastructure needs are modest but specific: proxies must not buffer the response (nginx proxy_buffering off or the X-Accel-Buffering: no header; Cache-Control: no-cache), compression must be streaming or off, and idle timeouts at the balancer must be longer than the gap between events, or the server must send a comment line (: keepalive) periodically. Every one of these is a configuration, not a protocol change.

WebSockets cover the fourth option: a bidirectional framed connection with the lowest per-message overhead and the highest infrastructure demands. The matrix puts the four side by side on the properties that actually decide the choice.

The decision is mostly about directionality and frequency. If updates are rare and clients are few, poll — it is the cheapest thing to operate. If the server pushes and the client speaks only occasionally through normal requests, SSE is enough for most "real-time" products: notifications, feeds, dashboards, progress bars, streaming responses; it needs no new infrastructure, reconnects on its own, and multiplexes over HTTP/2. Choose WebSockets when the client also sends frequently and latency matters in both directions — chat with typing indicators, multiplayer state, collaborative cursors, trading — or when binary framing matters. Keep long polling as the fallback that works when a corporate proxy breaks the others.

The emerging option is WebTransport: a browser API over HTTP/3 and QUIC that offers multiple independent streams (no head-of-line blocking between them) and unreliable datagrams for data where a late update is worse than a lost one — game state, media. It inherits QUIC’s properties and costs from HTTP/3 and QUIC, including the requirement that UDP/443 be reachable. Browser support is still uneven (Chromium-based browsers and Firefox ship it; Safari support lags as of 2026) and server support is limited to QUIC-capable stacks, so today it is a specialised tool, not a default; design with a WebSocket fallback.