Ping, jitter et 0 ms : lire un test de latence HTTP
Lisez les résultats de latence et de jitter du navigateur, comprenez les 0 ms et les connexions réutilisées, et pourquoi HTTP/3 utilise QUIC au lieu de TCP.
Lire ensemble la médiane, la plage et le jitter
L’outil de latence enregistre huit temps de réponse HTTP successifs après une requête de préchauffage. La médiane est la valeur centrale des mesures triées ; la plage indique la plus petite et la plus grande. Ici, le jitter (variation de latence) correspond à l’écart absolu moyen entre deux échantillons consécutifs, et non à une mesure au niveau des paquets.
Exemple avec huit valeurs : 20, 30, 10, 40, 20, 30, 10, 40 ms. Une fois triées, les deux valeurs centrales sont 20 et 30, soit une médiane de 25 ms. Les sept écarts consécutifs totalisent 140 ms ; divisés par sept, ils donnent une variation de 20 ms. Les valeurs vont de 10 à 40 ms. Ce sont des données illustratives pour le calcul, pas des mesures de la connexion d’un visiteur.
Ce que signifie 0 ms ou un minutage manquant
Les échantillons de temps de réponse et le détail de l’établissement de connexion sont des mesures distinctes. Une connexion réutilisée peut transporter une nouvelle requête sans nouvelle recherche DNS ni nouvelle négociation.
| Affichage | Signification | Étape suivante |
|---|---|---|
| En cache ou connexion réutilisée | Aucune nouvelle phase DNS n’a été mesurée pour cette requête | Ne l’interprétez pas comme la vitesse de résolution du résolveur DNS |
| Pas de nouvel établissement (connexion réutilisée) | L’entrée Resource Timing ne contient aucun nouvel intervalle d’établissement de connexion | Comparez les temps de réponse des requêtes au lieu de considérer l’établissement comme une latence aller-retour |
| TCP non utilisé (HTTP/3 · QUIC) | Cette requête a utilisé HTTP/3, dont le transport est QUIC | Consultez le RTT QUIC si le serveur périphérique en a communiqué un |
| Non communiqué | Le minutage requis était absent ou inexploitable | Considérez-le comme inconnu ; ce n’est pas un zéro mesuré |
| 0 ms communiqué (précision indisponible) | Le serveur périphérique a fourni un zéro sans précision suffisante pour l’interpréter davantage | N’en déduisez ni un délai physique nul ni une connexion réutilisée |
Comparer équitablement Wi-Fi, données mobiles ou VPN
Utilisez le même appareil et le même navigateur pour une petite comparaison. Le résultat est une observation de dépannage, pas une mesure étalonnée de l’ensemble de votre connexion Internet.
- Mettez en pause les téléchargements, les streams et tout autre trafic important, puis lancez l’outil de latence et notez la médiane, la plage et la variation.
- Ne modifiez que le réseau ou la configuration VPN que vous voulez comparer, attendez que la connexion se stabilise, puis recommencez.
- Notez plusieurs séries de mesures et l’heure du test. Si le serveur périphérique ou l’itinéraire observé change, considérez le résultat comme une comparaison des chemins complets.
- Utilisez la vérification TLS pour connaître le protocole HTTP et le RTT communiqué par le serveur périphérique. Ces métadonnées proviennent de leur propre requête d’inspection : elles ne correspondent donc pas forcément à un échantillon de latence.
Tenir un journal de comparaison qui explique les changements
Pour chaque série, notez l’heure, le nom du réseau, le réglage VPN, la médiane, la plage et la variation. Pour comparer un VPN, gardez le même Wi-Fi et le même appareil. Pour comparer le Wi-Fi aux données mobiles, ne changez pas le réglage VPN. Une médiane plus élevée après deux changements simultanés ne permet pas de savoir lequel en est la cause.
Comparez cet exemple à huit valeurs de 25 ms exactement : les deux médianes sont de 25 ms, mais la série constante va de 25 à 25 ms avec 0 ms de variation consécutive. Des médianes identiques peuvent masquer une régularité très différente. Ces exemples synthétiques isolent le calcul ; l’ordonnancement réel du navigateur ajoute du bruit. Répétez les essais inattendus et notez les indications d’établissement de connexion. N’ajoutez pas le RTT de l’edge au temps total de la requête du navigateur : les valeurs peuvent se chevaucher et provenir de requêtes différentes.
Pourquoi le ping du navigateur diffère du ping en jeu
Une requête HTTP inclut le travail du navigateur et du serveur en plus du temps réseau. Un jeu communique avec un autre serveur et peut utiliser un autre protocole. Un résultat Cloudflare proche ne permet pas de prédire la latence vers un serveur de jeu précis, et cet outil ne mesure ni le ping ICMP, ni la perte de paquets, ni le débit descendant.
Si votre objectif est d’héberger un jeu, utilisez la page « IP pour les jeux » pour préparer une adresse et examiner les indices WAN de votre box. En cas de lag en pleine partie, consultez aussi les statistiques réseau du jeu lui-même et refaites les tests au moment où le problème survient. Les indices de CGNAT et une latence élevée sont des observations distinctes ; l’une n’établit pas l’autre.
Questions fréquentes
Pourquoi le RTT TCP indique-t-il « non utilisé » avec HTTP/3 ?
HTTP/3 utilise QUIC plutôt que TCP. Le champ TCP ne s’applique pas à cette requête. IPNixa affiche le RTT QUIC séparément lorsque le serveur périphérique le communique.
0 ms signifie-t-il que ma connexion n’a aucun délai ?
Non. Une phase d’établissement peut être sautée sur une connexion réutilisée, ou un serveur peut indiquer un zéro sans précision suffisante pour l’interpréter. Ces cas sont signalés séparément des valeurs manquantes.
La latence mesurée par le navigateur équivaut-elle à un ping ICMP ?
Non. Ces échantillons chronomètrent de petites requêtes HTTP vers IPNixa, y compris le traitement par le navigateur et par le serveur. L’ICMP, les jeux et les autres destinations reposent sur des mesures différentes.
Ce test peut-il détecter une perte de paquets ou du bufferbloat ?
Non. Huit petites requêtes HTTP ne mesurent ni la perte de paquets ni la latence sous une charge d’envoi ou de téléchargement contrôlée. Utilisez un outil conçu pour ces mesures.