Prima la destinazione, non una soglia universale
Nei giochi veloci è generalmente preferibile un tempo di andata e ritorno basso e stabile verso il server del gioco. Le fasce sono indicazioni editoriali per il confronto, non uno standard ufficiale né una garanzia.
| Andata e ritorno indicata | Lettura orientativa |
|---|---|
| Sotto 50 ms | Un obiettivo di basso ritardo per interazioni rapide. |
| 50–100 ms | Può essere giocabile; verifica gioco e stabilità. |
| 100–150 ms | Il ritardo può risultare più evidente nei giochi veloci. |
| Oltre 150 ms | Spesso meno reattivo, ma non prova un guasto. |
Non applicare la tabella come requisito universale per chiamate o video. Le chiamate dipendono anche da jitter, perdite e buffer; il video precaricato dipende molto da capacità e stabilità. Un risultato del browser non certifica l’esperienza.
Ping, latenza e stabilità
Il normale comando ping usa eco ICMP. RTT comprende andata e ritorno; dividerlo per due non determina in modo affidabile il ritardo in una direzione, perché percorsi e code possono differire. I Mbps misurano capacità, non ritardo in ms.
Le variazioni sono spesso chiamate jitter; la perdita di pacchetti è un’altra misura. Registra destinazione e metodo: gli strumenti possono calcolare statistiche diverse.
Cosa misura IPdidi
Il test ping esegue 2 richieste di riscaldamento e 40 misurazioni HTTP a /ping.txt sul nodo Cloudflare che serve il sito. Non invia ICMP e non misura il server del gioco.
Usa normalmente l’intervallo da requestStart a responseStart, che può includere elaborazione del server. Se non disponibile, usa il tempo trascorso di fetch, compresa la lettura della risposta. Non garantisce RTT di rete puro.
Il jitter mostrato è la media della variazione assoluta tra campioni adiacenti riusciti. Timeout ed errori HTTP sono campioni falliti, non una percentuale di perdita di pacchetti IP. Le valutazioni d’uso sono euristiche del sito. La descrizione deriva dal codice, non da una prova sulla tua linea o sul tuo dispositivo.
Confronti ripetibili
- Annota destinazione, strumento, orario, Wi-Fi o cavo, VPN, media, variazioni ed errori.
- Ripeti a riposo e durante un normale download o upload, mantenendo uguali destinazione e metodo.
- Confronta Ethernet e Wi-Fi se possibile: aiuta a isolare fattori radio, senza garantire valori inferiori.
- Controlla la diagnostica del gioco o dell’app di chiamata. Un buon risultato verso un nodo non esclude problemi locali, di percorso, server o applicazione altrove.
Per ICMP, esegui ping example.com nel terminale e interrompi con Ctrl+C se continua. Un destinatario può filtrare l’eco: nessuna risposta non prova che il servizio sia fermo.
Una modifica, poi una misura
- Sospendi trasferimenti e backup per verificare code sotto carico.
- In Wi-Fi confronta posizione, bande o canali meno congestionati; 5 GHz non è sempre migliore attraverso muri o a distanza.
- Confronta una regione adatta del gioco e VPN attiva/disattiva nella stessa attività. VPN e piano più veloce non garantiscono latenza minore.
- Se il router gestisce le code, segui le istruzioni ufficiali. Può aiutare l’attesa, non eliminare la distanza di propagazione.
- Se persiste, fornisci all’assistenza destinazione, orari e risultati a riposo e sotto carico, non soltanto il minimo.
Usa lo stesso test prima e dopo. Non ricavare la causa soltanto dalla differenza fra due destinazioni.
Domande comuni
100 ms è sempre negativo?
Dipende da attività, destinazione, protocollo e stabilità. È una misura da indagare, non una soglia universale.
Un errore HTTP equivale a pacchetti persi?
No. Le cause possibili sono diverse e questo test non determina la perdita di rete.
Perché il gioco mostra un altro numero?
Destinazione, traffico ed elaborazione sono diversi. Confronta la sua diagnostica, senza sottrarre misure non correlate.
Fonti e ambito
La guida spiega misure e un processo di confronto. Non dichiara di individuare un guasto sulla tua connessione o di avere provato uno specifico dispositivo.
Fonti verificate: 2026-11-05.