Long Polling

Updated September 30, 20263 min read

In short

Long polling is a technique where a client sends a request that the server holds open until new data is ready, imitating real-time push over plain HTTP.

What is long polling?

Long polling is a way to get near-real-time updates using only ordinary HTTP requests. The client asks the server for new data, and instead of answering immediately with 'nothing yet', the server keeps the request open until something happens or a timeout, often 20 to 60 seconds, is reached. As soon as the client receives a response, it sends the next request, so there is almost always one request waiting.

With regular, or short, polling, the client asks every few seconds whether anything has changed, which wastes requests when nothing has and adds delay when something has. Long polling fixes both problems: responses arrive as soon as data exists, and empty responses happen only at the timeout. The server must be able to hold many idle requests open at once, which suits event-driven servers such as Node.js but can exhaust thread pools on servers that dedicate one thread to each request.

Regular polling is like a child in the back seat asking 'are we there yet?' every minute; long polling is like asking once and having the driver answer only when you arrive. Long polling powered early web chat and notification systems, and it is still used as a fallback when WebSocket connections are blocked, by some message queue and bot APIs that wait for new work, and wherever a simple, firewall-friendly approach is enough.

Long polling is often compared with Server-Sent Events and WebSocket. Long polling needs a new HTTP request for every message or batch, which adds header overhead and a short gap while the client reconnects, during which the server has to buffer new messages. Server-Sent Events keep one response open and stream many messages through it, and WebSocket opens a persistent two-way connection. Webhooks solve a related problem between servers: instead of the client waiting, the server calls the client's URL when an event happens.

Key takeaways

The server holds each request open until new data is available or a timeout expires.
The client sends a new request immediately after each response.
It delivers updates faster, and with fewer empty responses, than regular polling.
Every message costs a full HTTP request, so it is heavier than SSE or WebSocket.
It remains a useful fallback where persistent connections are blocked.

Example

A long polling client loopjavascript

// Keep one request waiting for new messages at all times
async function listen(lastId = 0) {
  while (true) {
    try {
      // The server replies only when there are messages newer than lastId,
      // or with an empty list after about 30 seconds
      const res = await fetch("/messages?after=" + lastId);
      const messages = await res.json();
      for (const m of messages) { show(m); lastId = m.id; }
    } catch {
      await new Promise((r) => setTimeout(r, 2000)); // wait before retrying
    }
  }
}

Readers ask

What is the difference between polling and long polling?

With regular polling, the server answers every request immediately, even when there is nothing new, so the client keeps asking on a timer. With long polling, the server waits to answer until there is new data, which cuts wasted requests and delivers updates sooner.

Is long polling still used?

Yes, though less for new browser features. It remains a fallback when WebSocket or SSE connections are blocked, and several queue and bot APIs use it so clients can wait efficiently for new work.

What timeout should long polling use?

Commonly 20 to 60 seconds, kept shorter than the idle timeouts of the proxies and load balancers along the path, which are often around 60 seconds. Otherwise an intermediary may cut the connection before the server responds.