Short Polling: cos'è, come funziona e dove viene utilizzato

Cos'è Short Polling

Short Polling è un modello di comunicazione in cui il client invia periodicamente richieste HTTP al server a un intervallo predefinito, e il server elabora ogni richiesta in modo sincrono e restituisce immediatamente il risultato. L'intervallo di polling è impostato sul lato client utilizzando timer e di solito varia da 1 a 60 secondi a seconda dei requisiti di aggiornamento dei dati.

Short Polling è storicamente il primo meccanismo per organizzare la comunicazione in tempo reale nelle applicazioni web. All'inizio degli anni 2000, prima della seconda generazione di XMLHttpRequest, le pagine web utilizzavano <meta http-equiv="refresh"> o il ricaricamento periodico di iframe per aggiornare i contenuti. Con l'avvento della tecnologia AJAX (Asynchronous JavaScript and XML) nel 2005, Short Polling è diventato l'approccio standard per aggiornare i dati senza ricaricare completamente la pagina.

Architettura di Short Polling

L'architettura di Short Polling include tre componenti: un timer client, una richiesta HTTP e un gestore server. Il client avvia un timer a intervallo, e a ogni attivazione viene inviata una richiesta GET al server. Il server interroga un database o un'altra fonte, crea una risposta e la restituisce immediatamente al client. Il client aggiorna l'interfaccia e attende la successiva attivazione del timer. Questo ciclo si ripete indefinitamente finché l'applicazione è attiva.

Il problema delle richieste ridondanti

Il problema principale di Short Polling sono le inevitabili richieste vuote. Se i dati cambiano raramente, la maggior parte delle richieste restituisce un risultato "nessuna modifica", sprecando larghezza di banda di rete e tempo CPU per l'elaborazione. Con 10.000 client con intervallo di polling di 5 secondi, il server riceve 2.000 richieste al secondo — una parte significativa delle quali è inutile se la frequenza di aggiornamento è di 1 evento al minuto.

Come funziona Short Polling

Short Polling funziona in un ciclo semplice: il client imposta un timer a intervallo con un periodo determinato (ad esempio, 5000 ms). A ogni attivazione del timer, il client crea una richiesta HTTP GET all'endpoint del server, di solito con un parametro di timestamp dell'ultimo aggiornamento. Il server riceve la richiesta, verifica la presenza di nuovi dati dopo il timestamp specificato e restituisce una risposta — o con nuovi dati o con un indicatore di assenza di aggiornamenti.

Un parametro critico di configurazione di Short Polling è l'intervallo di polling. Un intervallo troppo breve (meno di 3 secondi) crea un carico elevato sul server e sulla rete. Un intervallo troppo lungo (più di 30 secondi) riduce l'attualità dei dati. L'intervallo ottimale dipende dallo scenario: per i dashboard di monitoraggio — 5–15 secondi, per i feed di notizie — 30–60 secondi, per gli avvisi critici — 1–3 secondi. La scelta dell'intervallo è sempre un compromesso tra l'attualità dei dati e il carico sull'infrastruttura.

Intervallo di polling adattivo

Per ridurre il carico durante l'inattività, si utilizza un intervallo adattivo: se diverse richieste consecutive restituiscono un risultato vuoto, l'intervallo aumenta (ad esempio, da 5 a 15 secondi). Quando compaiono nuovi dati, l'intervallo viene reimpostato al valore minimo. L'algoritmo di backoff esponenziale (exponential backoff) consente di ridurre il numero di richieste vuote di 3–5 volte durante aggiornamenti poco frequenti.

Esempio di implementazione di Short Polling in JavaScript

Vediamo un'implementazione lato client di Short Polling utilizzando setInterval e Fetch API. La funzione prende l'URL dell'endpoint e l'intervallo di polling in millisecondi.

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("Ricevuto", data.updates.length, "updates");
            }
        } catch (error) {
            console.error("Polling fallito:", error);
        }
    }, intervalMs);

    return timerId;
}

const timer = startPolling("/api/updates", 5000);
// clearInterval(timer) per fermare

Il codice crea un intervallo di polling di 5 secondi e passa il timestamp dell'ultimo aggiornamento al server. Il server può utilizzare questo parametro per filtrare i dati e restituire solo i nuovi record, riducendo la quantità di informazioni trasmesse. La funzione restituisce l'identificatore del timer per consentire l'arresto del polling.

Lato server di Short Polling

L'implementazione lato server per Short Polling è estremamente semplice — è un normale endpoint REST che accetta richieste GET e restituisce una risposta JSON con lo stato corrente o i dati modificati dopo il timestamp specificato.

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);

Il server riceve il parametro since e filtra i record il cui timestamp supera il valore specificato. Questo approccio minimizza la quantità di dati in ogni risposta, restituendo solo le modifiche incrementali. Quando non ci sono nuovi dati, il server restituisce un array vuoto e il client continua il polling secondo il programma.

Short Polling vs Long Polling

Short Polling e Long Polling risolvono lo stesso problema — la consegna dei dati dal server al client — ma differiscono radicalmente in efficienza. Short Polling utilizza un intervallo di richiesta fisso, creando un carico prevedibile, mentre Long Polling mantiene la connessione aperta fino al verificarsi di un evento, minimizzando il numero di risposte vuote.

La scelta tra le tecniche dipende dalla frequenza di aggiornamento dei dati. Se gli eventi si verificano più di una volta ogni 10 secondi — entrambi gli approcci generano un carico comparabile, e Short Polling può essere più semplice. Se gli eventi sono rari (ore o minuti tra le modifiche) — Long Polling è preferibile perché non crea richieste vuote. Per scenari intermedi, la scelta dipende dai vincoli infrastrutturali e dalla possibilità di utilizzare WebSocket.

Quando si usa Short Polling

Short Polling viene utilizzato in scenari in cui i requisiti di aggiornamento dei dati sono bassi e la semplicità di implementazione ha priorità sull'efficienza. I casi più tipici sono i pannelli amministrativi interni, i sistemi di monitoraggio con bassa frequenza di avvisi e le applicazioni in cui un ritardo di 15–30 secondi è accettabile.

• Dashboard di monitoraggio — dashboard con metriche che si aggiornano ogni 10–30 secondi, senza richiedere reazione immediata ai cambiamenti.
• Pagine di stato — pagine di verifica della disponibilità dei servizi in cui i dati si aggiornano ogni 30–60 secondi e il ritardo non è critico.
• Report analitici — sistemi di analisi interni con raccolta periodica di dati in cui l'attualità fino a 1 minuto è accettabile.
• Giochi semplici — giochi multiplayer a turni senza requisiti di tempo reale, in cui il turno si aggiorna ogni pochi secondi.
• Test — scenari di test di carico e debug in cui Short Polling viene utilizzato come metodo di polling di riferimento per il confronto con altre tecniche.

Limitazione importante — Short Polling non è adatto per applicazioni sensibili al tempo (terminali di trading, sistemi di allerta di emergenza) in cui anche un ritardo di 1 secondo è inaccettabile. In tali scenari, è necessario utilizzare WebSocket, Server-Sent Events o Long Polling. Quando si progetta un sistema con Short Polling, è necessario calcolare il budget delle richieste: con 1.000 client con intervallo di 5 secondi, il server elabora 12.000 richieste al minuto, il che richiede una base di risorse corrispondente.