Long polling vs short polling
Short polling has the client ask the server for updates on a fixed timer and get an answer straight away, empty or not. Long polling has the server hold each request open until it actually has something to send. Both imitate push over plain HTTP; long polling trades held connections for lower latency.
Short polling vs long polling at a glance
Short polling trades latency for simplicity: updates arrive up to one interval late, and most requests return empty. Long polling trades server resources for latency: updates arrive almost immediately, but every waiting client holds a connection open. The table shows where each cost lands.
| Aspect | Short polling | Long polling |
|---|---|---|
| Latency to an update | Up to one polling interval | Milliseconds after the update exists |
| Requests per update | Many, most of them empty | About one |
| Server state | None between requests | Tracks every waiting client |
| Connection budget | Brief requests spread over time | One connection held open per client |
| Failure mode | A missed poll is retried on the next tick | Reconnect loops and duplicates when a response races a timeout |
How short polling works
The client sends a request every few seconds and the server replies immediately with whatever it has. Most of those replies are empty, which is the whole cost of the technique: if updates arrive once a minute and you poll every five seconds, eleven out of twelve requests did nothing but burn a round trip. In exchange you get something genuinely simple. Each request is independent, nothing is held open, and a client that crashes just stops asking. Caching, load balancers, and timeouts all behave normally because the traffic looks like ordinary API calls.
Short polling fits data that changes on a schedule you already know, such as a nightly report status, a health check, or a feed where being a minute stale costs nothing.
How long polling works
The client sends a request and the server does not answer until an update exists or a timeout expires, usually somewhere between 20 and 60 seconds. When the response finally comes back the client immediately opens another request, so there is almost always a connection waiting. Updates reach the client within milliseconds of being available rather than on the next tick of a timer.
The price is that every waiting client occupies a connection and, depending on your server model, a thread or a goroutine. A thousand idle clients on short polling is a thousand brief requests spread over time; on long polling it is a thousand connections held open at once. That is fine on an event-driven server and expensive on a thread-per-request one. Long polling also needs more care around edge cases: proxies that kill idle connections, clients that reconnect in a tight loop after an error, and duplicate delivery when a response is sent as the client gives up.
What each costs you
Short polling wastes requests but keeps state on the client. Long polling wastes almost no requests but moves state onto the server, which now has to track who is waiting and wake them up. Which one is cheaper depends on the ratio between your polling interval and how often data actually changes. Poll infrequently against data that rarely changes and short polling wins on simplicity. Poll every second because users expect near-instant updates and long polling is doing strictly less work for a better result.
There is a browser-side limit worth knowing before you commit to long polling. Over HTTP/1.1 a browser opens at most six concurrent connections per origin, so one held-open poll permanently consumes a sixth of the page’s budget and competes with every image, script, and API call on the same host. HTTP/2 removes that ceiling by multiplexing requests over one connection, but any intermediate proxy that terminates at HTTP/1.1 puts it back.
Neither approach scales as well as a protocol designed for the job. Both are workarounds for HTTP’s request/response shape, which is why they lose to server-sent events or WebSockets once you can rely on those being available. If you are weighing polling against a continuous feed more generally, polling vs streaming covers that framing.
Choosing between them
Pick short polling when the update interval is measured in minutes, the client count is high, and simplicity matters more than freshness. Pick long polling when users notice a delay of a few seconds and you cannot use a streaming protocol, which is common behind older proxies or in environments where only plain HTTP gets through.
If the updates come from another company’s system rather than your own, polling is usually the wrong frame entirely. Webhooks invert the direction so the provider tells you when something happened instead of you asking on a loop. Our comparison of webhooks and long polling covers that tradeoff, and Svix handles the delivery side for teams sending those events to their own users.