An In-Depth Study of Short Polling: The Fundamental Strategy for Real-Time Communication

In the nascent stages of web development, the term "real-time" communication was more or less synonymous with polling. Before the advent of WebSockets, Server-Sent Events (SSE), and HTTP/2 streaming, short polling was the preferred solution for constructing apps requiring up-to-the-minute data. This was despite the fact that it necessitated constant queries to the server, incessantly asking, "Do you have any updates?"

Short polling is a technique involving frequent, regular HTTP requests made by a client to check for updates. It's straightforward to implement, compatible with any backend stack, and doesn't require special infrastructure. However, it does come with certain constraints, particularly when dealing with large-scale systems.

This article provides a deep dive into the workings of short polling, its continued relevance, and its judicious application in contemporary frontend systems.

The Inner Workings of Short Polling

The fundamental mechanism of short polling is uncomplicated:

setInterval(() => {
  fetch("/api/notifications")
    .then((res) => res.json())
    .then((data) => updateUI(data));
}, 3000);

At regular intervals, the browser sends a request to the server for fresh data. If there's no new data available, the response is either empty or unchanged. If new data is available, the UI updates accordingly.

This is a fire-and-forget mechanism. There's no maintenance of a persistent connection — just repeated round-trip communications.

The Continued Relevance of Short Polling

Despite being considered "old school," short polling retains its relevance in certain circumstances:

• Infrequent updates (e.g., checking for new messages)
• Environments where WebSockets or SSE are blocked
• Lightweight, transient UIs that do not justify complex infrastructure
• Rapid prototypes or apps without a real-time backend

Short polling sacrifices efficiency for simplicity, which can be the optimal choice in certain situations.

Limitations and Potential Issues with Short Polling

Short polling can be very resource-intensive:

• Wasted requests when no data changes
• Unnecessary load on backend and databases
• Scalability issues under high traffic
• Delays between polling cycles, leading to reduced real-time fidelity

For instance, polling every 5 seconds amounts to up to 12 server hits per minute for each user. Multiply this by 10,000 users, and your API could potentially be handling millions of needless calls every hour.

Short Polling in the Real World

Gmail (early versions)

In its earlier iterations, Gmail utilized short polling to check for new emails. Every N seconds, the frontend would ping the server to inquire about any changes.

Slack (fallback mode)

Slack primarily employs WebSockets, but it reverts to short polling if connections fail. This ensures usability even in networks with restrictions.

IoT Dashboards

Devices that sporadically send data, such as sensors or smart meters, often use polling from a centralized UI to fetch updates in a predictable loop.

Best Practices for Short Polling

• Use backoff if the user is idle or the tab is hidden
• Poll only visible or active views
• Utilize ETag or Last-Modified headers for lightweight diffs
• Cache prior responses and compare to avoid unnecessary redraws
• Transition to long polling or WebSockets as needs evolve

Here's an example of using backoff and visibility:

document.addEventListener("visibilitychange", () => {
  if (document.visibilityState === "visible") {
    startPolling();
  } else {
    stopPolling();
  }
});

Short Polling Anti-Patterns

• Polling every second without any caching or deduplication
• Polling across various tabs (instead of using BroadcastChannel or SharedWorker)
• Ignoring the risk of stale data if the response lags behind the interval
• Not backing off during errors or timeouts

Polling is simple, but without proper protections, it can inadvertently lead to a DDoS attack against your own backend.

Alternatives to Short Polling

• Long Polling: Keeps the request open until data arrives
• Server-Sent Events: One-way push from server to client
• WebSockets: Full-duplex, real-time streams
• GraphQL Subscriptions: Real-time data via GraphQL transport

Short polling can be a stepping stone to these more sophisticated models and can also serve as a fallback when they aren't feasible.

Conclusion: Polling with Purpose

Short polling offers real-time capabilities without the need for complex infrastructure. It's a minimalist approach to imparting responsiveness to your UI — no sockets, no special protocols, just repeated requests.

When used judiciously, it can provide real value. However, misuse can result in server failures.

Poll with purpose. Optimize aggressively. And understand when it's time to upgrade.

Because sometimes, asking repeatedly is sufficiently effective — until it isn't.