Test ping, jitter e 0 ms: leggere la latenza HTTP
Interpreta latenza e jitter nel browser, valori di 0 ms e connessioni riutilizzate. Scopri perché HTTP/3 usa QUIC e in cosa il test differisce dal ping.
Leggi insieme mediana, intervallo e jitter
Lo strumento di latenza registra otto tempi di risposta HTTP in sequenza dopo una richiesta iniziale di preparazione. La mediana è il valore centrale delle misurazioni ordinate; l’intervallo mostra il minimo e il massimo. Qui il jitter è la media delle variazioni assolute tra campioni consecutivi, non una misura a livello di pacchetto.
Esempio con otto campioni: 20, 30, 10, 40, 20, 30, 10, 40 ms. Ordinandoli, la coppia centrale è 20 e 30, quindi la mediana è 25 ms. Le sette variazioni consecutive sommano 140 ms; dividendo per sette si ottengono 20 ms di variazione. L’intervallo è 10–40 ms. Sono dati illustrativi del calcolo, non misurazioni della connessione di un visitatore.
Cosa significa un tempo di 0 ms o non disponibile
I tempi di risposta e il dettaglio delle fasi di apertura sono misurazioni separate. Una connessione riutilizzata può gestire una nuova richiesta senza una nuova risoluzione DNS o un nuovo handshake.
| Valore mostrato | Significato | Cosa fare |
|---|---|---|
| In cache o connessione riutilizzata | Per questa richiesta non è stata misurata una nuova fase DNS | Non interpretarlo come la velocità di risoluzione del resolver DNS |
| Nessuna nuova apertura (connessione riutilizzata) | La voce Resource Timing non contiene un nuovo intervallo di apertura della connessione | Confronta i tempi di risposta delle richieste, senza interpretare l’apertura come latenza di andata e ritorno |
| TCP non utilizzato (HTTP/3 · QUIC) | Questa richiesta ha usato HTTP/3, il cui protocollo di trasporto è QUIC | Leggi il QUIC RTT se il nodo edge lo ha comunicato |
| Non comunicato | Il dato temporale richiesto era assente o non utilizzabile | Lascialo come sconosciuto: non è uno zero misurato |
| 0 ms comunicati (precisione non disponibile) | Il nodo edge ha fornito zero senza precisione sufficiente per interpretarlo ulteriormente | Non dedurre da questo campo un ritardo fisico nullo o il riutilizzo della connessione |
Confronta Wi-Fi, dati mobili o VPN in modo coerente
Per un confronto semplice, usa lo stesso dispositivo e browser. Il risultato è un’osservazione utile alla diagnosi, non una misurazione calibrata dell’intera connessione internet.
- Metti in pausa download, streaming e altro traffico intenso, poi avvia lo strumento di latenza e annota mediana, intervallo e variazione.
- Cambia solo la rete o la configurazione VPN che vuoi confrontare, attendi che la connessione si stabilizzi e ripeti.
- Annota più esecuzioni e l’ora del test. Se cambia il nodo edge osservato o il percorso, considera il risultato come un confronto tra i percorsi completi.
- Usa Verifica TLS per il protocollo HTTP e l’RTT riportato dal nodo edge. Questi metadati provengono da una richiesta di verifica distinta, quindi non devono necessariamente coincidere con un campione di latenza.
Annota i confronti per capire cosa è cambiato
Per ogni esecuzione, annota l’ora, il nome della rete, l’impostazione VPN, la mediana, l’intervallo e la variazione. Se vuoi confrontare una VPN, mantieni invariati Wi-Fi e dispositivo. Se vuoi confrontare Wi-Fi e dati mobili, non cambiare l’impostazione VPN. Una mediana più alta dopo due modifiche contemporanee non rivela quale delle due l’abbia causata.
Confronta l’esempio con otto campioni di esattamente 25 ms: entrambe le mediane sono 25 ms, ma la sequenza costante ha un intervallo di 25–25 ms e una variazione consecutiva di 0 ms. Mediane uguali possono nascondere una regolarità molto diversa. Questi esempi sintetici isolano il calcolo; la pianificazione reale del browser aggiunge rumore. Ripeti le prove inattese e annota le etichette di apertura della connessione. Non sommare l’RTT dell’edge al tempo totale della richiesta del browser: i valori possono sovrapporsi e provenire da richieste diverse.
Perché il ping nel browser differisce da quello nei giochi
Una richiesta HTTP comprende il lavoro del browser e del server oltre al tempo di rete. Un gioco comunica con un altro endpoint e può usare un protocollo diverso. Un risultato verso un nodo Cloudflare vicino non può prevedere la latenza verso uno specifico server di gioco, e questo strumento non misura ping ICMP, perdita di pacchetti o velocità di download.
Se vuoi ospitare una partita, usa la pagina IP per il gaming per preparare un indirizzo ed esaminare gli indizi WAN del router. Per i ritardi durante il gioco, consulta anche le statistiche di rete del gioco e ripeti i test quando si presenta il problema. Gli indizi di CGNAT e una latenza elevata sono osservazioni distinte: una non dimostra l’altra.
Domande frequenti
Perché TCP RTT indica «non utilizzato» con HTTP/3?
HTTP/3 usa QUIC anziché TCP. Il campo TCP non si applica a quella richiesta. IPNixa mostra il QUIC RTT separatamente quando il nodo edge lo comunica.
0 ms significa che la connessione non ha ritardo?
No. Una fase di apertura può essere saltata quando la connessione viene riutilizzata, oppure un server può riportare zero senza la precisione necessaria per interpretarlo. Questi casi sono indicati separatamente dai valori mancanti.
La latenza nel browser equivale al ping ICMP?
No. Questi campioni misurano piccole richieste HTTP a IPNixa, inclusi i tempi di elaborazione del browser e dell’endpoint. ICMP, giochi e altre destinazioni usano misurazioni diverse.
Questo test rileva perdita di pacchetti o bufferbloat?
No. Otto piccole richieste HTTP non misurano la perdita di pacchetti né la latenza durante un carico controllato in upload o download. Usa uno strumento progettato per queste misurazioni.