WebSockets vs HTTP Polling
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.
// 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.
Practice what you learned
1. What is the main drawback of short polling?
2. How does long polling differ from short polling?
3. Why can long polling be resource-intensive for a server at scale?
4. In which scenario is simple short polling likely still the better engineering choice over WebSockets?
5. What allows a WebSocket server to handle many idle connections more cheaply than a long-polling server often can?
Was this page helpful?
You May Also Like
What Are WebSockets?
An introduction to the WebSocket protocol, a persistent, full-duplex communication channel over a single TCP connection used for real-time web applications.
WebSockets vs Server-Sent Events
Understanding when to choose bidirectional WebSockets versus the simpler, unidirectional Server-Sent Events (SSE) protocol for server-to-client streaming.
The WebSocket Handshake
A step-by-step look at how a WebSocket connection is established, from the initial HTTP Upgrade request to the server's 101 Switching Protocols response.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentgRPC Study Notes
Protocol Buffers · 30 topics
Web DevelopmentSpring Boot Study Notes
Java · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics
Web DevelopmentNext.js Study Notes
JavaScript · 30 topics