WebSockets vs HTTP Polling

Analogy categoryAnalogies

Short polling is the simplest technique for getting near-real-time data over plain HTTP: the client repeatedly sends a request at a fixed interval asking 'anything new?', and the server replies immediately, even when nothing has changed. It's easy to implement but wasteful, since most requests return empty results, and the delay before a client notices a change is bounded by the polling interval.

🏏

Cricket analogy: Like a fan who doesn't have live TV coverage repeatedly texting a friend at the stadium every two minutes asking 'any wickets yet?', getting 'no' replies most of the time until something finally happens.

Short Polling vs Long Polling

Long polling improves on short polling by having the server hold the client's request open until new data becomes available (or a timeout elapses), rather than replying immediately with 'nothing yet.' This cuts down on wasted empty responses, but the client must still reissue a brand-new HTTP request as soon as the current one resolves, so per-message overhead like headers and connection setup remains.

🏏

Cricket analogy: Like asking the stadium announcer to hold the phone line open and only speak when the next wicket actually falls, rather than calling back every minute — better, but you still redial after each wicket.

javascript

// Short polling
async function pollForUpdates() {
  const res = await fetch('/api/messages/latest');
  const data = await res.json();
  renderMessages(data);
}
setInterval(pollForUpdates, 5000); // every 5s, even if nothing changed

// Long polling
async function longPoll() {
  try {
    const res = await fetch('/api/messages/wait'); // server holds request open
    const data = await res.json();
    renderMessages(data);
  } finally {
    longPoll(); // immediately reopen for the next update
  }
}
longPoll();

Why WebSockets Win for Real-Time Needs

WebSockets amortize the connection setup cost into a single upgrade handshake, then stream messages over the same open socket with minimal per-message overhead, letting the server push data the instant it's ready instead of waiting for the client to ask. At scale, this also tends to be lighter on server resources than long polling, since a modern WebSocket server can multiplex thousands of idle connections using event-driven I/O rather than dedicating a thread or held-open request to each waiting client.

🏏

Cricket analogy: Like a stadium's dedicated commentary line kept open to every broadcaster's studio for the whole match, versus each studio's runner physically walking to the ground booth after every over.

Long polling reduces wasted empty responses compared to short polling, but at scale it still costs the server a held-open HTTP connection (and often a thread or socket) per waiting client. A WebSocket server, by contrast, can multiplex thousands of idle connections cheaply using event-driven I/O, since no request is 'pending' waiting to time out.

When Polling Is Still the Right Choice

For low-frequency updates, polling remains a perfectly reasonable choice: it's simpler to implement and debug, works naturally with standard HTTP caches and CDNs, doesn't require sticky sessions on a load balancer, and passes through restrictive corporate firewalls and proxies far more reliably than a protocol upgrade. If a summary only needs to refresh every few minutes, the operational simplicity of polling usually outweighs the latency benefits of a persistent connection.

🏏

Cricket analogy: Like a fan happy to check the newspaper's morning score summary once a day rather than needing ball-by-ball commentary for a match they only casually follow.

Don't reach for WebSockets by default. If updates are infrequent (say, once every few minutes), simple short polling with exponential backoff is easier to build, debug, and scale behind ordinary caches and load balancers — and it survives restrictive corporate proxies that may block WebSocket upgrades.

Short polling repeatedly asks the server 'anything new?' at fixed intervals, wasting requests when nothing changed.
Long polling holds the HTTP request open until data is available, cutting empty responses but still requiring reconnection per update.
WebSockets amortize the HTTP overhead into a single upgrade handshake, then stream data over the same open connection.
At scale, long polling can consume significant server resources holding many pending connections open.
WebSockets typically deliver lower latency because the server can push data the instant it's ready.
Polling remains a reasonable choice for infrequent updates, simple caching needs, or restrictive network environments.
The right choice depends on update frequency, latency requirements, and infrastructure constraints, not just what's newest.