Long Polling: What It Is, How It Works, and Where It’s Used

What is Long Polling

Long Polling is a communication pattern in a client-server architecture where a client initiates an HTTP request, and the server delays sending a response until new data becomes available or a specified timeout expires. After receiving the response, the client immediately sends the next request, creating the effect of a continuous connection.

The Long Polling technique emerged as an evolutionary development of Short Polling to reduce the number of empty HTTP requests. In traditional polling, the client sends requests every N seconds, and the server responds even when there is no new data. In Long Polling, the server uses a connection holding mechanism, which dramatically reduces useless traffic.

The History of Long Polling

Before the advent of WebSocket in 2011, Long Polling was the primary method for real-time communication on the web. Companies such as Facebook and Gmail used this technique for their chats and notifications in the early 2010s. According to High Performance Browser Networking (Grigorik, 2013), Long Polling handled up to 95% of all real-time connections in major web applications of that period.

Basic Principle of Long Polling

A client sends a standard HTTP request to the server. Upon receiving the request, the server does not return a response immediately — it places the request in a waiting queue. When an event occurs on the server (a new message, data change), the server forms a response and sends it to the client. Upon receiving the response, the client immediately creates a new Long Polling request, and the cycle repeats.

How Long Polling Works

Long Polling works according to the following sequence of steps. The client sends an HTTP GET request to a server endpoint. Upon receiving the request, the server checks for new data in the event queue. If there is no data, the server holds the request in a waiting state, not sending a response immediately. The holding mechanism depends on the server implementation — most often asynchronous processing with callbacks or event-driven architecture is used.

When an event occurs on the server side (for example, a user sent a message in a chat), the server forms an HTTP response with a body containing this data and terminates the connection. The client receives the response, processes the data, and immediately initiates a new request. If no data appears during the waiting period, the server sends an empty response after the timeout expires, and the client also re-establishes the connection. The timeout is usually 30–60 seconds for a balance between load and latency.

Timeouts and Connection Management

A key configuration parameter for Long Polling is the waiting timeout. A timeout that is too short (less than 10 seconds) leads to an increase in the number of requests, bringing the technique closer to Short Polling. A timeout that is too long (more than 120 seconds) may cause connection breaks by intermediate proxies and load balancers. The recommended value for most scenarios is 30–45 seconds.

Handling Multiple Events

If multiple events occur on the server during a single Long Polling request, the server must transmit them all in one response or organize an event queue on the client side. For this purpose, event buffering is used: the server accumulates events that occurred during the holding time of the request and transmits them as an array of data in the response body.

Long Polling Implementation Example in JavaScript

Let’s look at a simple Long Polling implementation on the client side using the modern Fetch API. The client function sends a request and recursively calls itself after receiving a response.

async function longPoll(url) {
    try {
        const response = await fetch(url);
        const data = await response.json();

        handleData(data);
        longPoll(url);
    } catch (error) {
        console.error("Long Polling error", error);
        setTimeout(() => longPoll(url), 3000);
    }
}

function handleData(data) {
    if (data.events && data.events.length > 0) {
        data.events.forEach(event => {
            console.log("New event:", event);
        });
    }
}

longPoll("/api/events");

This code creates an infinite Long Polling loop: after receiving a response, the function immediately sends a new request. In case of a connection error, a three-second delay is set before retrying to avoid avalanche load on the server.

Server Implementation on Node.js

On the server side, it is necessary to hold the request until an event occurs or a timeout expires. An implementation example using EventEmitter in Node.js demonstrates this mechanism.

const express = require("express");
const EventEmitter = require("events");
const app = express();

const eventBus = new EventEmitter();

app.get("/api/events", (req, res) => {
    const timeout = setTimeout(() => {
        res.json({ events: [] });
    }, 30000);

    eventBus.once("new-event", (data) => {
        clearTimeout(timeout);
        res.json({ events: [data] });
    });
});

app.post("/api/events", (req, res) => {
    eventBus.emit("new-event", req.body);
    res.send({ status: "ok" });
});

app.listen(3000);

The server part uses EventEmitter to notify waiting Long Polling connections when new data appears. Upon reaching the 30-second timeout, the server returns an empty array of events, and the client creates a new request.

When to Use Long Polling

Long Polling is used in scenarios where real-time data delivery is required but using WebSocket is impossible due to technical or infrastructural reasons. The most common cases are corporate proxies and firewalls that block WebSocket connections, as well as environments with limited protocol support on the server side.

• Chats and messengers — Long Polling provides message delivery in web versions of messengers operating over HTTP without WebSocket.
• Dashboard panels — real-time systems for DevOps metrics, logs, and alerts where data timeliness with 1–5 second delay is important.
• Notifications — push-like delivery of alerts in the browser without using Service Workers and Push API.
• Activity feeds — social networks and news feeds with automatic content updates when new posts appear.
• Collaboration — Google Docs-like editors with basic synchronization of changes between users.

The key factor in choosing Long Polling is backward compatibility. All HTTP clients and servers support this method, making it a universal solution for real-time functionality without additional dependencies. According to HTTP Archive (2024), about 8% of all websites continue to use Long Polling for basic real-time functionality.

Long Polling vs Short Polling

Long Polling and Short Polling solve the same problem — data delivery from server to client — but fundamentally differ in mechanism and efficiency. Short Polling uses a fixed polling interval where the client sends HTTP requests at equal time intervals regardless of whether new data has appeared on the server.

Short Polling is simpler to implement but creates significantly more load on the server and network with the same data update frequency. If a latency of less than 5 seconds is required, Short Polling generates dozens of requests per minute, while Long Polling uses one request per event or timeout. For applications with infrequent events, Long Polling is orders of magnitude more traffic-efficient.

Long Polling vs WebSocket

WebSocket is a full-fledged bidirectional real-time protocol operating over TCP after an initial HTTP handshake. Unlike Long Polling, WebSocket establishes a single persistent connection and allows the server to send data to the client at any time without creating a new HTTP request.

The choice between Long Polling and WebSocket depends on several factors. Compatibility: Long Polling works through any proxies and firewalls, while WebSocket may be blocked by corporate networks. Performance: WebSocket has lower overhead (2 bytes per frame versus full HTTP headers), which is critical at high message frequency. Scalability: Long Polling requires more server-side resources due to holding many connections, while WebSocket uses a fixed connection per session.

• Long Polling — the best choice for applications with low event frequency (1–10 events per minute), limited infrastructure, or the need to support older browsers.
• WebSocket — the optimal solution for high-load real-time applications (stock exchange data, online games, collaborative editors) with hundreds of messages per second.
• Hybrid approach — some applications use Long Polling as a fallback for clients that do not support WebSocket, with automatic protocol switching.

According to Mozilla Developer Network (2024), WebSocket is supported by all modern browsers since versions 2011–2015, but corporate proxies (e.g., Symantec Blue Coat) continue to block it in 15–20% of corporate networks, which keeps Long Polling relevant as a fallback solution.