What Is Long Polling? A Simple Real-Time Alternative

Long polling is a technique for approximating real-time updates over plain HTTP: the client sends a request, and instead of responding immediately, the server holds that request open until it actually has new data to send — or until a timeout is reached — then the client immediately opens a new request and the cycle repeats. It predates WebSockets and Server-Sent Events as a way to get push-like behavior out of a request/response protocol that was never designed for it.

How it differs from regular polling

Ordinary polling is simple but wasteful: the client asks “anything new?” every few seconds, and most of those requests come back empty, because the interval is a guess rather than tied to when data actually changes. Shorten the interval to reduce latency and you multiply the wasted requests; lengthen it to save requests and you increase the delay before a client notices new data.

Long polling breaks that tradeoff. Instead of the server answering immediately with “nothing new,” it holds the connection open and only responds once there’s something to say — or once a timeout forces a response, at which point the client just reconnects and waits again. The client makes roughly one request per update instead of one request per polling interval, and updates arrive close to the moment they happen rather than on the next scheduled check.

The request lifecycle

A typical long-polling exchange looks like this:

1. The client sends a request to an endpoint, e.g. GET /updates.
2. The server does not respond immediately. It holds the request open, often by parking the connection while some other part of the system (a queue, a pub/sub channel, a database trigger) watches for relevant new data.
3. When new data arrives, the server responds with it and closes that request.
4. The client processes the response and immediately issues a new request, repeating the cycle.
5. If no new data arrives within some server-defined timeout (commonly 20-60 seconds), the server responds with an empty result anyway, and the client reconnects — this prevents connections from hanging indefinitely and gives both sides a chance to recover from network issues.

Because each cycle is a normal HTTP request and response, long polling works through any infrastructure that already handles HTTP — proxies, load balancers, corporate firewalls — without needing a protocol upgrade the way WebSockets do.

Where it still makes sense

WebSockets and Server-Sent Events are generally better fits for real-time features today, but long polling still has real advantages in specific situations:

• Restrictive network environments. Some corporate proxies and older infrastructure block WebSocket upgrade requests but pass ordinary HTTP through without issue. Long polling degrades gracefully in exactly those environments.
• Infrequent updates. If new data genuinely arrives every few minutes rather than continuously, the overhead of maintaining a persistent WebSocket connection may not be worth it compared to occasionally reopening a plain request.
• Simpler infrastructure. A long-polling endpoint is just an HTTP endpoint that happens to wait before responding — it needs no special server support, no separate protocol handling, and works with the same load balancers and API gateways as the rest of your REST API.

The costs

Long polling’s simplicity comes at a real cost compared to a persistent connection:

• Held-open connections consume server resources. Each open request typically ties up a worker thread, socket, or connection slot until it resolves — at high concurrency this can exhaust server capacity faster than a WebSocket server, where many idle connections cost comparatively little.
• Latency has a floor set by request overhead. Every cycle pays the cost of a new TCP handshake (unless connections are kept alive) and a full set of HTTP headers, which is unnecessary overhead compared to a WebSocket sending a small frame over an already-open connection.
• It’s strictly one direction per open request. The server can push data when it holds a request open, but the client can’t send anything mid-hold without opening a separate request — true bidirectional communication needs a different mechanism entirely.

Long polling vs the alternatives

Server-Sent Events solve the same “server needs to push data” problem with a single long-lived connection instead of a repeated request cycle, which is more efficient when updates are frequent, but SSE is one-directional and text-only. WebSockets go further, offering a full-duplex, binary-capable persistent connection, at the cost of needing a protocol upgrade that not every piece of network infrastructure handles cleanly. Long polling remains the fallback that works almost everywhere, because it never stops being a plain HTTP request underneath.

A pragmatic pattern in several widely used libraries is to attempt a WebSocket connection first and transparently fall back to long polling if the upgrade fails or the connection drops unexpectedly. The application code sees a single consistent interface for sending and receiving messages, while the underlying transport quietly adapts to whatever the network in front of a given client will actually allow.

The takeaway

Long polling gets push-like behavior out of ordinary HTTP by having the server delay its response until there’s actually something to send, trading the wasted round trips of fixed-interval polling for held-open connections that cost server resources instead. It’s mostly a fallback today, given how widely WebSockets and Server-Sent Events are supported, but it remains the technique that works through network infrastructure that blocks anything fancier — which is exactly why it hasn’t disappeared.