Comment ce test mesure ta connexion
Cette page décrit exactement ce que PingPacketTest.com envoie, comment ça devient les trois chiffres de la page d’accueil et — dans la dernière partie — ce que ces chiffres ne peuvent pas dire. Si tu ne lis qu’une partie, lis la dernière.
Ce que le test envoie vraiment
Le navigateur ouvre un DataChannel WebRTC vers un des serveurs de mesure et y envoie de petits paquets. Le canal est configuré avec ordered: false et maxRetransmits: 0 : le navigateur n’a le droit ni de renvoyer un paquet, ni d’en retenir un parce qu’un précédent manque. C’est donc du vrai UDP — le même transport que presque tous les jeux en ligne utilisent.
Chaque paquet porte un numéro et son heure de départ, complété à la taille de paquet du jeu choisi. Le serveur fait une seule chose : il le renvoie tel quel. L’aller-retour est donc mesuré entièrement dans ton navigateur, avec une seule horloge. Un paquet dont l’écho n’arrive jamais compte comme perdu.
Pourquoi un speedtest ne répond pas à cette question
Un speedtest mesure le débit en TCP. TCP est fait pour cacher le problème que tu cherches : un paquet perdu est renvoyé en silence, et il reste à la fin un débit un peu plus faible.
Un jeu ne fait pas ça. Il envoie une position à rythme fixe et passe à la suite ; une mise à jour perdue n’est jamais renvoyée. C’est pour ça qu’une ligne peut réussir tous les speedtests et produire quand même du rubberbanding. Mesurer sur un transport non fiable est la seule façon de le voir.
Tick rate : pourquoi le jeu choisi change la mesure
Un serveur de jeu fait avancer le monde par pas fixes — les ticks. Ce rythme décide à quelle fréquence les paquets passent sur ta ligne et combien un retard donné coûte : à 128 ticks, 60 ms d’aller-retour représentent presque huit mises à jour, à 20 ticks à peine une.
Choisir un jeu ici change donc le rythme d’envoi et la taille des paquets de la mesure elle-même. Le rythme de chaque titre, sa source et s’il est vérifié ou estimé sont dans la base de données des tick rates.
Où sont les serveurs de mesure
Il y en a quatre : New York, San Jose, Francfort et Singapour. Ton navigateur mesure par défaut contre le plus proche ; tu peux changer pour vérifier une route précise. Le serveur utilisé figure sur chaque résultat, car un ping sans destination ne veut rien dire.
Comment les chiffres sont calculés
La première seconde ne compte pas. Chaque mesure commence par une seconde d’échauffement : des paquets partent, mais rien n’est compté. Les premiers paquets d’une route sont plus lents, et ce coût appartient à l’établissement de la connexion, pas à ta ligne. Ça ne vaut qu’au début : une coupure en pleine mesure apparaît entièrement.
Le ping est une médiane, avec toute la plage derrière. Le graphique dessine un point toutes les 100 ms ; le point montre la médiane des paquets de cette tranche, la bande ombrée le plus bas et le plus haut. Rien n’est lissé : un paquet à 400 ms étire la bande jusqu’à 400 ms.
La perte de paquets n’est jamais moyennée. Un seul paquet perdu dessine sa marque à chaque niveau de zoom. Un paquet compté perdu qui arrive finalement retrouve son statut : il était en retard, pas perdu.
Le jitter est mesuré sur des fenêtres fixes d’une seconde (écart-type des allers-retours de chaque seconde, moyenné sur la mesure). Ainsi, la même ligne affiche le même jitter à tous les tick rates. Un aller-retour au-delà de 1000 ms compte comme perdu.
Comment le verdict et le percentile sont établis
Le verdict prend le pire des trois chiffres, pas la moyenne. 20 ms de ping avec 2 % de perte n’est pas une bonne connexion. Les seuils de jitter découlent du tick rate (un demi-tick pour « bon », un tick pour « jouable », plafonnés à 15 et 30 ms) ; ceux du ping sont un jugement, publié ici : 30/60 ms à partir de 100 Hz, 40/80 ms à 60–64 ticks, 60/100 ms à 30 ticks, 80/150 ms en dessous. Pour la perte, la limite est la même partout : au-dessus de 1 %, ce n’est pas assez bon.
Le percentile te compare aux mesures faites ici, pas à internet. Les personnes qui font un test de perte de paquets ne sont pas un échantillon aléatoire — beaucoup viennent parce que quelque chose ne va pas.
Ce que signifie la ligne Type de NAT
Pendant la mesure, la ligne d’état indique le type de la paire de candidats ICE réellement utilisée : host pour un chemin public direct, server-reflexive pour un passage à travers un NAT qui a permis une route directe, relay pour une connexion passée par un intermédiaire. Affiché comme Ouvert, Modéré et Strict, les mots des menus de console. Un navigateur ne peut pas lire la valeur de ta console ; c’est l’observation équivalente.
Comment les coupures et la disponibilité sont comptées
Au-delà d’une minute, l’outil dit ce que la ligne a fait sur la durée. Une coupure est une période d’au moins une seconde pleine où chaque fenêtre de 100 ms a perdu au moins un paquet. La disponibilité est la part du temps mesuré hors de ces périodes. Les valeurs sont calculées une fois, à la fin, et enregistrées avec le résultat.
Ce que ce test ne peut pas dire
On mesure la route vers notre serveur, pas vers le serveur du jeu. Si la route vers Francfort est propre et que ton jeu saccade quand même, le problème peut se trouver entre ton fournisseur et le centre de données du jeu.
Un aller-retour ne dit pas dans quel sens un paquet s’est perdu. Et ce n’est pas un traceroute : la mesure prouve une perte sur la route dans son ensemble, sans désigner l’étape fautive.
Si UDP est bloqué, le test repasse en TCP. Le ping reste parlant, mais la perte apparaît plus faible qu’en réalité, car TCP renvoie les paquets. Même chose via un relais (TURN) : le chemin est plus long que ta vraie route.
On mesure ta connexion telle qu’elle est, avec tout ce qui l’utilise. Un téléchargement, une console qui se met à jour ou un stream dans la maison entrent dans le résultat. Si une mesure est mauvaise, refais-la avec tout le reste coupé.
Un navigateur n’est pas un environnement temps réel. Une machine très chargée ou un onglet en arrière-plan peut ajouter un peu de jitter qui vient de ton appareil, pas de ton fournisseur.
Ce n’est pas un test de débit. Et rien sur ce site n’est un échantillon aléatoire d’internet : chaque comparaison publiée dit « parmi les tests faits ici ».
Pour aller plus loin
La base de données des tick rates liste chaque jeu avec le rythme envoyé, sa source et son statut. Les statistiques de perte de paquets et la statistique en direct sont en anglais. Le test démarre dès que tu l’ouvres.
Questions, corrections ou erreur de méthode : info@pingpackettest.com.