AJAX Polling

Short polling is setInterval(fetch, n): the client repeatedly asks “anything new?” and the server replies, usually with nothing. Latency is up to n seconds and most responses are empty. And yet it’s often the right call.

When polling is fine

• Updates are rare or freshness isn’t critical — a job status that changes every few seconds, a dashboard refreshed every minute.
• The infrastructure doesn’t support long-lived connections.
• You want the simplest thing that works and can be cached, retried and load-balanced like any other request.

Making it cheap

The cost is easy to estimate: requests per second ≈ clients ÷ interval. A hundred thousand clients polling every five seconds is twenty thousand requests a second of mostly nothing. So:

• Use conditional requests (ETag / If-None-Match) so unchanged data returns a tiny 304 Not Modified.
• Back off when the tab is hidden (document.visibilityState).
• Add jitter so clients don’t synchronise into spikes.
• Let a data library do it: TanStack Query’s refetchInterval or SWR’s refreshInterval handle most of this for you.

The four techniques side by side

Technique	Direction	Latency	Server cost	Use when
Short polling	client asks	up to the interval	many empty requests	rare updates, simplest infrastructure
HTTP Long Polling	server answers when ready	low	held connections	fallback, legacy, job queues
Server-Sent Events (SSEs)	server → client	low	one connection per client	feeds, progress, notifications, token streams
WebSockets	both ways	lowest	one stateful connection	chat, collaboration, games, trading

In practice

On a workflow platform I worked on, process status views were a textbook polling case: status changed every few seconds, nobody needed millisecond freshness, and polling with a sensible interval was far simpler to operate than a socket infrastructure. Pick the technique from the freshness your users actually need, not from what sounds most impressive.