Short Polling: What It Is, How It Works and Where It Is Used

What is Short Polling

Short Polling is a communication pattern where the client periodically sends HTTP requests to the server at a predefined interval, and the server processes each request synchronously and immediately returns the result. The polling interval is set on the client side using timers and typically ranges from 1 to 60 seconds depending on data freshness requirements.

Short Polling is historically the first mechanism for organizing real-time communication in web applications. In the early 2000s, before the second generation of XMLHttpRequest, web pages used <meta http-equiv="refresh"> or periodic iframe reloads to update content. With the advent of AJAX (Asynchronous JavaScript and XML) technology in 2005, Short Polling became the standard approach for updating data without a full page reload.

Short Polling Architecture

The Short Polling architecture includes three components: a client timer, an HTTP request, and a server handler. The client starts an interval timer, and each time it fires, a GET request is sent to the server. The server queries a database or other source, forms a response, and immediately returns it to the client. The client updates the interface and waits for the next timer tick. This cycle repeats indefinitely while the application is active.

The Problem of Redundant Requests

The main problem with Short Polling is inevitable empty requests. If data changes infrequently, most requests return a "no changes" result, wasting network bandwidth and CPU time on processing. With 10,000 clients polling every 5 seconds, the server receives 2,000 requests per second — a significant portion of which is useless if the update frequency is 1 event per minute.

How Short Polling Works

Short Polling works on a simple cycle: the client sets an interval timer with a given period (e.g., 5000 ms). On each timer tick, the client forms an HTTP GET request to the server endpoint, usually with a timestamp parameter of the last update. The server receives the request, checks for new data after the specified timestamp, and returns a response — either with new data or an indicator that no updates are available.

A critical configuration parameter for Short Polling is the polling interval. Too short an interval (less than 3 seconds) creates high server and network load. Too long an interval (more than 30 seconds) reduces data freshness. The optimal interval depends on the scenario: for monitoring dashboards — 5–15 seconds, for news feeds — 30–60 seconds, for critical alerts — 1–3 seconds. Choosing the interval is always a trade-off between data freshness and infrastructure load.

Adaptive Polling Interval

To reduce load during idle periods, adaptive interval is used: if several consecutive requests return an empty result, the interval increases (e.g., from 5 to 15 seconds). When new data appears, the interval resets to the minimum value. The exponential backoff algorithm can reduce the number of empty requests by 3–5 times during infrequent updates.

Short Polling Implementation Example in JavaScript

Let's look at a client-side Short Polling implementation using setInterval and the Fetch API. The function takes an endpoint URL and a polling interval in milliseconds.

function startPolling(url, intervalMs) {
    const lastTimestamp = new Date().toISOString();

    const timerId = setInterval(async () => {
        try {
            const params = new URLSearchParams({
                since: lastTimestamp
            });
            const response = await fetch(url + "?" + params);
            const data = await response.json();

            if (data.updates && data.updates.length > 0) {
                renderUpdates(data.updates);
                console.log("Received", data.updates.length, "updates");
            }
        } catch (error) {
            console.error("Polling failed:", error);
        }
    }, intervalMs);

    return timerId;
}

const timer = startPolling("/api/updates", 5000);
// clearInterval(timer) to stop

The code creates a polling interval of 5 seconds and passes the timestamp of the last update to the server. The server can use this parameter to filter data and return only new records, reducing the amount of transmitted information. The function returns the timer identifier to allow stopping the polling.

Server-Side Short Polling

The server-side implementation for Short Polling is extremely simple — it is a regular REST endpoint that accepts GET requests and returns a JSON response with the current state or data changed after the specified timestamp.

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

let items = [];

app.get("/api/updates", (req, res) => {
    const since = req.query.since;
    const filtered = items.filter(item => item.timestamp > since);
    res.json({ updates: filtered });
});

app.listen(3000);

The server receives the since parameter and filters records whose timestamp exceeds the specified value. This approach minimizes the amount of data in each response, returning only incremental changes. When there is no new data, the server returns an empty array, and the client continues polling on schedule.

Short Polling vs Long Polling

Short Polling and Long Polling solve the same problem — delivering data from the server to the client — but differ dramatically in efficiency. Short Polling uses a fixed request interval, creating predictable load, while Long Polling holds the connection open until an event occurs, minimizing the number of empty responses.

The choice between techniques depends on the update frequency of the data. If events occur more often than once every 10 seconds — both approaches produce comparable load, and Short Polling may be simpler. If events are rare (hours or minutes between changes) — Long Polling is preferable as it does not create empty requests. For intermediate scenarios, the choice depends on infrastructure constraints and the ability to use WebSocket.

When to Use Short Polling

Short Polling is used in scenarios where data freshness requirements are low and implementation simplicity takes priority over efficiency. The most typical cases are internal admin panels, monitoring systems with low alert frequency, and applications where a 15–30 second delay is acceptable.

• Monitoring Dashboards — dashboards with metrics that update every 10–30 seconds, not requiring instant response to changes.
• Status Pages — service availability check pages where data updates every 30–60 seconds and delay is not critical.
• Analytics Reports — internal analytics systems with periodic data collection where freshness of up to 1 minute is acceptable.
• Simple Games — turn-based multiplayer games without real-time requirements, where turns update every few seconds.
• Testing — load testing and debugging scenarios where Short Polling is used as a reference polling method for comparison with other techniques.

Important limitation — Short Polling is not suitable for time-critical applications (trading terminals, emergency alert systems) where even a 1-second delay is unacceptable. In such scenarios, you need to use WebSocket, Server-Sent Events, or Long Polling. When designing a system with Short Polling, you should calculate the request budget: with 1,000 clients polling every 5 seconds, the server processes 12,000 requests per minute, which requires a corresponding resource base.