Long polling

Sometimes a page needs to react the moment something happens on the server: a new chat message, a price update, a “your order shipped” notice. Plain HTTP is request-and-response, so the server can’t just push to you whenever it likes. Long polling is a trick that gets close to push behavior using nothing but ordinary fetch calls.

It’s the simplest way to hold a persistent connection with a server without reaching for a dedicated protocol like WebSocket or Server-Sent Events. Easy to build, and good enough for a large share of real cases.

Regular polling

Before long polling, look at the naive version: just ask, over and over.

The client sends a request on a timer — say, once every 10 seconds — that effectively says “anything new for me?” The server does two things with that request. It notes that this client is still online, and it hands back whatever messages piled up since the last check.

It works. But two things hurt:

1. A message can sit on the server for up to 10 seconds before the next poll picks it up. That delay is baked into the interval.
2. The server gets hit every 10 seconds by every client, even when nothing is happening and even when the user wandered off to another tab or fell asleep. Multiply that by many clients and it’s real load for no benefit.

For a tiny service you might not care. Past that, it needs work.

Try it below. The “client” polls once every 3 seconds, whether or not anything is waiting. Queue a message on the server at any moment and watch how long it sits until the next poll happens to come around — that wait is the latency baked into the interval.

<button id="rp-send">Queue a message on the server</button>
<div id="rp-status">No message waiting yet. The client polls every 3s.</div>
<div id="rp-log"></div>

button{padding:7px 14px;border:1px solid #7c3aed;background:#7c3aed;color:#fff;border-radius:6px;cursor:pointer;font-size:14px}
#rp-status{margin:12px 0 8px;color:#52525b;font-size:13px}
#rp-log{height:150px;overflow-y:auto;padding:10px;background:#f4f4f5;border:1px solid #e4e4e7;border-radius:8px;font:13px ui-monospace,Menlo,monospace}
#rp-log div{padding:2px 0}

const btn = document.getElementById('rp-send');
const status = document.getElementById('rp-status');
const log = document.getElementById('rp-log');

let pending = null;      // the message sitting on the server, if any
let queuedAt = 0;        // when it was queued

btn.addEventListener('click', function () {
pending = 'hello!';
queuedAt = Date.now();
status.textContent = 'A message is now waiting on the server…';
});

function line(text, color) {
const el = document.createElement('div');
el.textContent = text;
el.style.color = color;
log.appendChild(el);
log.scrollTop = log.scrollHeight;
}

// The client asks on a fixed timer, nothing more.
setInterval(function () {
if (pending) {
  const waited = ((Date.now() - queuedAt) / 1000).toFixed(1);
  line('poll → got "' + pending + '"  (it waited ' + waited + 's for this poll)', '#166534');
  pending = null;
  status.textContent = 'Delivered. Queue another to see the delay again.';
} else {
  line('poll → nothing new', '#a1a1aa');
}
}, 3000);

Long polling

Long polling keeps the request/response shape but changes one thing: the server refuses to answer until it actually has something to say.

The flow:

1. The client sends a request to the server.
2. The server holds the connection open — it does not respond — while it has no message.
3. As soon as a message appears, the server answers that pending request with it.
4. The client receives the response and immediately fires off a fresh request.

So at almost any moment there’s a request sitting open, waiting. The connection only closes when a message is actually delivered, and then it’s reopened right away. A message reaches the client the instant the server has it, with no polling delay in between.

There’s one more case to handle: the connection dropping. If the network hiccups and the request dies, the client just opens a new one right away and carries on.

Here’s a sketch of a client-side subscribe function that keeps these long requests going:

async function subscribe() {
  let response = await fetch("/subscribe");

  if (response.status == 502) {
    // Status 502 is a connection timeout error,
    // may happen when the connection was pending for too long,
    // and the remote server or a proxy closed it.
    // Let's reconnect.
    await subscribe();
  } else if (response.status != 200) {
    // An error - let's show it.
    showMessage(response.statusText);
    // Reconnect in one second.
    await new Promise(resolve => setTimeout(resolve, 1000));
    await subscribe();
  } else {
    // Get and show the message.
    let message = await response.text();
    showMessage(message);
    // Call subscribe() again to get the next message.
    await subscribe();
  }
}

subscribe();

The shape is a loop dressed up as recursion: subscribe fetches, waits for the response, deals with whatever came back, and then calls itself to start the next request. Three branches cover the three outcomes.

• 502 is the timeout case. Proxies and servers often cap how long a connection may hang. When one closes a request that was pending too long, you get a 502, which here means “nothing arrived, but that’s fine” — so reconnect at once, no error shown.
• Any other non-200 is a genuine problem. Show it, wait a second so you don’t hammer a struggling server, then reconnect.
• 200 is the happy path. Read the message body, display it, and immediately open the next request.

Demo: a chat

Here’s the same idea running right here, with the “server” faked in memory so there’s no real network. The client keeps one request open at all times (watch the status line). The moment you send something, the pending request resolves with your message and a fresh one opens immediately — that’s the near-instant delivery long polling gives you, with no interval to wait out.

<div id="lp-status">starting…</div>
<div id="lp-log"></div>
<div id="lp-row">
<input id="lp-input" placeholder="type a message and hit Send" />
<button id="lp-send">Send</button>
</div>

#lp-status{margin-bottom:8px;color:#7c3aed;font-size:13px;font-family:ui-monospace,Menlo,monospace}
#lp-log{height:170px;overflow-y:auto;padding:10px;background:#f4f4f5;border:1px solid #e4e4e7;border-radius:8px;font:13px ui-monospace,Menlo,monospace}
#lp-log div{padding:2px 0}
#lp-row{display:flex;gap:8px;margin-top:10px}
#lp-input{flex:1;padding:7px 10px;border:1px solid #d4d4d8;border-radius:6px;font-size:14px}
button{padding:7px 16px;border:1px solid #7c3aed;background:#7c3aed;color:#fff;border-radius:6px;cursor:pointer;font-size:14px}

const statusEl = document.getElementById('lp-status');
const log = document.getElementById('lp-log');
const input = document.getElementById('lp-input');
const sendBtn = document.getElementById('lp-send');

// ---- fake server (in memory, no network) ----
let queue = [];          // messages waiting if no request is open
let deliver = null;      // resolve() of the currently pending request

// The server "holds the connection open": it returns a promise that only
// settles once a message exists.
function serverAwaitMessage() {
return new Promise(function (resolve) {
  if (queue.length) resolve(queue.shift());
  else deliver = resolve;
});
}
function serverReceive(text) {
if (deliver) { const d = deliver; deliver = null; d(text); }
else queue.push(text);
}

function line(text, color) {
const el = document.createElement('div');
el.textContent = text;
el.style.color = color;
log.appendChild(el);
log.scrollTop = log.scrollHeight;
}

// ---- client: the never-ending subscribe loop ----
async function subscribe() {
statusEl.textContent = '● request open — pending, waiting for a message…';
const message = await serverAwaitMessage();   // resolves the instant one arrives
line('◀ received: ' + message, '#166534');
statusEl.textContent = '✓ delivered — reopening a fresh request…';
await subscribe();                            // immediately open the next one
}

sendBtn.addEventListener('click', function () {
const text = input.value.trim();
if (!text) return;
input.value = '';
line('▶ sent to server: ' + text, '#52525b');
serverReceive(text);
});
input.addEventListener('keydown', function (e) {
if (e.key === 'Enter') sendBtn.click();
});

subscribe();

In a real app the browser-side code lives in a file like browser.js, and serverAwaitMessage is a fetch("/subscribe") that the server leaves hanging until it has news.

When to use it

Long polling shines when messages are relatively rare. Each open request costs almost nothing while it waits, and delivery is prompt when something finally happens.

The picture changes when messages come thick and fast. Every message ends its request and starts a new one, so a steady stream turns the request/response graph into a saw-tooth of constant open-close-open-close.

Every one of those requests carries the full baggage of an HTTP request: headers, cookies, authentication, connection setup. When that repeats many times per second, the overhead dominates and you’re better off with a channel built for it, such as WebSocket or Server-Sent Events.