What is long polling in one sentence?

Long polling is a technique where the client makes an HTTP request that the server holds open until new data is ready, then returns it and the client immediately reconnects — approximating real-time push over ordinary HTTP.

How is long polling different from regular polling?

Regular polling asks 'anything new?' on a fixed interval and usually gets 'no,' wasting requests. Long polling asks once and waits; the server answers only when there is data, cutting empty round trips and latency.

Long polling vs WebSockets — which is better?

WebSockets are better for frequent, two-way, low-latency messaging. Long polling is simpler, works everywhere HTTP works, and is fine for infrequent updates or as a fallback where WebSockets are blocked.

Is long polling obsolete?

No. It remains a reliable fallback through restrictive proxies and older clients, and real-time libraries still use it as a transport of last resort. WebSockets and SSE are usually preferred when available.

What about Server-Sent Events?

Server-Sent Events (SSE) keep one HTTP connection open for a continuous server-to-client stream with automatic reconnection. They are lighter than WebSockets when you only need one-directional push.

Glossary · Web Platform

Long Polling vs WebSockets

Long polling is an old but durable trick for faking real-time updates over plain HTTP: the client sends a request, the server holds it open instead of answering immediately, and replies only when there is fresh data — at which point the client reconnects and waits again. It is the simpler cousin of WebSockets, and knowing when each one fits is the real lesson.

From polling to long polling

The naive way to get updates is short polling: ask the server "is there anything new?" every few seconds. Most of those requests come back empty, burning bandwidth and adding latency equal to the interval. Long polling fixes both problems by inverting the wait — the client asks once, and the server simply does not respond until it has something to send (or a timeout fires). The reply arrives the instant data is ready, and the client reopens the request to keep the cycle going.

Why it endured

Long polling's superpower is that it is just HTTP. There is no protocol upgrade, no special server support, and no new ports — it sails through corporate proxies, old browsers, and restrictive firewalls that mangle anything exotic. For years it was the only broadly compatible way to get push-like behavior on the web, and even now it survives as the fallback transport inside real-time libraries when a WebSocket connection cannot be established.

Where WebSockets win

For anything chatty and bidirectional, WebSockets are simply better. After the initial handshake, a WebSocket holds one persistent, full-duplex connection, so messages flow both ways with minimal overhead and no per-message reconnect. Long polling, by contrast, pays the cost of a fresh HTTP request and response for every update, and a true back-and-forth conversation means a constant churn of reconnections. A chat app, a multiplayer game, or a live trading screen wants WebSockets.

Where long polling still fits

Long polling holds up well when updates are infrequent and flow only from server to client — a job-status indicator, a notifications badge, an occasional alert. The implementation is trivial on both ends, it inherits all of HTTP's caching, auth, and load-balancing machinery, and there is no persistent-connection state to scale. When you do not actually need a live two-way socket, choosing long polling avoids the operational tax that a WebSocket layer carries.

Do not forget SSE

There is a third option people overlook: Server-Sent Events. SSE keeps a single HTTP connection open for a continuous server-to-client stream and handles reconnection automatically, making it lighter than WebSockets when push only needs to go one direction. The honest decision tree is: SSE or long polling for one-way updates, WebSockets for frequent two-way traffic, and for service-to-service streaming consider gRPC instead.

At QUANT LAB

We pick the transport to match the traffic rather than reaching for the flashiest option. Plenty of "real-time" requirements are satisfied by SSE or long polling, which are dramatically simpler to operate and scale than a persistent socket fleet. When a product genuinely needs low-latency, two-way messaging, our API development work builds the WebSocket layer properly — with a long-polling fallback for clients stuck behind hostile proxies. The right answer is usually the least complex thing that meets the latency budget.

Long-form deep-dives that use this term

All posts

Related terms

Choosing a real-time transport?

We help teams pick between long polling, SSE, and WebSockets, then build it to scale. Book a 30-minute call.

API development