Votre navigateur chronomètre 10 vrais allers-retours HTTPS vers Azure Front Door en passant par votre Wi-Fi, votre fournisseur d’accès et un éventuel VPN ou proxy, puis affiche la médiane, la première connexion et la gigue.
Snif, snif… on est où ?
Recherche de votre IP de sortie…
Une fois les requêtes terminées, vous verrez à quelle vitesse répond Azure Front Door depuis ici.
Pour comparer, la page d’accueil teste Azure Front Door avec les autres services de la catégorie Fournisseurs CDN : Cloudflare, Akamai, Amazon CloudFront, Google Cloud CDN, Fastly. Azure Front Door passe par le réseau de Azure Front Door : l’aller-retour s’arrête donc au datacenter Azure Front Door le plus proche, et non sur les serveurs de Azure Front Door.
C’est l’adresse que les sites voient quand vous les visitez. À la maison, elle appartient en général à votre fournisseur d’accès. Avec un VPN, un proxy, le réseau du bureau ou le relais privé iCloud, elle appartient à celui qui relaie votre trafic, parfois dans une autre ville ou un autre pays. Elle décide aussi vers quel serveur un service vous envoie, donc votre vitesse.
Parce que beaucoup de proxys et de VPN font du routage séparé, c’est-à-dire choisissent la route selon le site : certains sites passent en direct, les autres par le proxy. Une seule vérification d’IP ne voit que sa propre route. Nous en interrogeons donc plusieurs (1ms.dog, un site en Chine continentale, Cloudflare, ip.sb, ipinfo.io, IPv4 seule, IPv6 seule, WebRTC en UDP), regroupons les résultats par réseau et marquons chaque sortie en direct ou proxy. Si des services d’habitude bloqués dans votre pays répondent, nous signalons une sortie restée invisible.
Votre navigateur ouvre une vraie connexion HTTPS avec chaque service. La première requête sert uniquement à établir la connexion (résolution DNS, échanges TCP et TLS) : elle est affichée à part et n’est pas comptée. La même connexion sert ensuite à quelques requêtes chronométrées, dont nous affichons la médiane. C’est l’aller-retour de votre appareil au serveur le plus proche, via votre Wi-Fi, votre fournisseur et un éventuel proxy : le délai que vos applis ressentent vraiment.
Le ping utilise ICMP, que les navigateurs ne peuvent pas envoyer, et beaucoup de réseaux traitent ICMP autrement que le trafic normal : un bon ping ne garantit donc pas une appli rapide. La mesure HTTPS suit le même chemin que vos applis. Les chiffres sont en général quelques millisecondes au-dessus du ping, car le serveur doit répondre à une requête.
Éclair ≤ 30 ms : comme dans la même ville. Sprint ≤ 80 ms : même région. Trot ≤ 150 ms : suffisant pour presque tout. Balade ≤ 300 ms : ça se sent dans les jeux et les appels. Sieste > 300 ms : très loin, ou route encombrée. Pas revenu : aucune connexion en 5 secondes, donc inaccessible d’ici. Sous les 2 ms, vous débloquez le légendaire chien 1ms.
Vos résultats ne nous sont pas envoyés. Les requêtes de latence partent directement de votre navigateur vers les services testés. Pour trouver votre IP de sortie, il interroge 1ms.dog et quelques services publics d’IP, qui voient donc votre IP : c’est le principe même. Votre dernier résultat reste dans ce navigateur, pour repérer les changements. Un résultat ne quitte votre navigateur que si vous le partagez ou signalez un problème. Un lien partagé contient le pays et les temps, plus la ville et le réseau seulement si vous cochez la case, et jamais d’adresse IP. Sur 1ms.dog, le lien est raccourci et une image du résultat est enregistrée pour son aperçu dans les messageries. Après un test complet, votre navigateur échange aussi quelques minuscules messages avec notre serveur de Tokyo pour mesurer l’aller-retour ; il ne garde aucun journal.
Tout se passe dans votre navigateur. Pas de compte, et nous ne collectons pas vos résultats.
© 2026 1ms.dog