Que mesure cet outil ?
Quel datacenter de chaque grand CDN vous sert, à quelle distance il se trouve et quelle latence vous avez.
Un CDN garde des copies des sites dans des datacenters répartis dans le monde, aussi appelés PoP ou nœuds. Plus celui qui vous sert est proche, plus les sites de ce CDN se chargent vite, en général. Mais un CDN ne vous envoie pas toujours vers le plus proche.
Votre navigateur télécharge un petit fichier sur chaque CDN, comme lorsqu'il ouvre un site, et lit quel datacenter a répondu. La page affiche ensuite la distance, la latence et le minimum permis par cette distance.
Ces requêtes vont directement de votre navigateur aux CDN, sans passer par ce site.
Pourquoi suis-je servi par un datacenter lointain ? Est-ce grave ?
En général, votre appareil n'y est pour rien : c'est le CDN et votre fournisseur d'accès qui ont choisi cette route.
Pourquoi : les CDN ne choisissent pas seulement selon la distance. Cloudflare et d'autres utilisent l'anycast, où une même adresse fonctionne depuis de nombreux endroits à la fois, et c'est le réseau de votre fournisseur qui choisit le chemin. Akamai, CloudFront et d'autres choisissent selon l'emplacement de votre serveur DNS. En Chine continentale, les sites sur les offres gratuite et d'entrée de gamme de Cloudflare sont souvent servis depuis la côte ouest des États-Unis ou d'autres datacenters lointains sur de nombreux réseaux, car ces routes coûtent moins cher. Seul le China Network payant (avec JD Cloud) sert depuis la Chine continentale ou Hong Kong.
Conséquence : plus le datacenter est loin, plus chaque requête met de temps à faire l'aller-retour. Pages, images et vidéos se chargent plus lentement, et tout peut davantage ramer aux heures de pointe.
Ce que vous pouvez faire : avec un proxy ou un VPN, le CDN vous sert selon l'emplacement du proxy ; comparez avec « Tester seulement en direct ou seulement via le proxy ». Si vous utilisez un DNS public comme 8.8.8.8, revenir à celui de votre fournisseur peut vous donner un datacenter plus proche avec les CDN qui choisissent par DNS. Vous pouvez aussi comparer avec un autre réseau, par exemple la 4G/5G et votre box. Le CDN et l'offre d'un site, seul le site peut les changer.
Comment le datacenter est-il lu ?
Chaque CDN l'écrit dans sa réponse, à sa façon :
Cloudflare : le champ colo de /cdn-cgi/trace (HKG).
Amazon CloudFront : l'entrée cdn-pop de Server-Timing, ou X-Amz-Cf-Pop (NRT57-P11).
Akamai : Akamai-Request-BC, qui nomme la ville (JP_13_TOKYO).
Fastly : X-Served-By (cache-nrt-…-NRT).
Azure Front Door : X-Azure-Ref (…C1TYO…).
Bunny : l'en-tête Server (BunnyCDN-JP1-…).
Wikimedia : X-Cache, où le numéro du serveur de cache identifie le datacenter.
Un navigateur ne peut lire ces informations que si la réponse l'autorise ; chaque CDN est donc testé avec un fichier public dont la réponse l'autorise. Google, Alibaba Cloud, Tencent EdgeOne, Wangsu, Gcore et CDN77 ne l'autorisent pas : seule leur latence est mesurée.
Qu'est-ce que la latence minimum possible ?
C'est la latence la plus basse que permet la distance. Une vraie connexion ne peut pas être plus rapide.
Dans la fibre, la lumière parcourt environ 200 km par milliseconde. Pour un aller-retour sur une distance d, la latence ne peut pas descendre sous d ÷ 100 ms. Les routes réelles sont en général 1,5 à 2 fois plus longues que la ligne droite.
Quand la latence dépasse le double de ce minimum plus 40 ms, elle est marquée « Détour » : la route fait un détour ou attend sur une liaison saturée.
Que veut dire « Pas le plus proche » ?
Le CDN a un datacenter plus proche de vous, mais ne l'a pas utilisé.
Pour les CDN qui publient tous leurs datacenters (Cloudflare, Bunny, Wikimedia), la page trouve le plus proche de vous. Si celui qui a répondu est plus loin de plus de 1 000 km et plus de deux fois plus loin, c'est signalé.
Ce n'est pas une panne : le CDN ou votre fournisseur a choisi une autre route. Pour savoir pourquoi et quoi faire, voir « Pourquoi suis-je servi par un datacenter lointain ? Est-ce grave ? ».
Comment fonctionne la vérification d'un site ?
Saisissez un domaine pour voir quel CDN il utilise, quel datacenter vous sert et votre latence.
Le Worker de ce site interroge le DNS de Cloudflare pour ce domaine, afin qu'une réponse locale ou falsifiée ne le trompe pas, et reconnaît le CDN d'après la cible de son CNAME. Il interroge aussi /cdn-cgi/trace sur le site pour repérer Cloudflare et, si le site l'autorise, lit le datacenter dans les en-têtes de son favicon. Enfin, il mesure la latence du site.
Le domaine est envoyé au Worker de ce site et au DNS de Cloudflare. Ce site ne le conserve pas.
D'où vient ma position ?
De votre adresse IP, localisée par Cloudflare (ce site fonctionne sur Cloudflare). Elle est en général juste à la ville près, mais peut se tromper de plusieurs centaines de kilomètres, et avec un proxy c'est la position du proxy.
« Utiliser la position précise » utilise celle de votre navigateur. Elle ne sert que dans cette page et n'entre dans un lien de partage, arrondie à environ 10 km, que si vous cochez la case en partageant.
Mes données sont-elles collectées ?
Ce site ne conserve pas vos résultats.
Les requêtes de test vont directement de votre navigateur à chaque CDN, qui voit votre adresse IP comme n'importe quel site que vous visitez. Ce site n'aide la page que pour trois choses : votre position approximative d'après votre IP ; les noms de ville des codes de datacenter ; et, grâce à une requête DNS de plus qui arrive au serveur DNS de ce site, quel serveur DNS vous utilisez et s'il transmet votre bloc d'adresses (gardé 2 minutes en mémoire, jamais dans un lien ou une carte de partage).
Un lien de partage contient les datacenters et la latence. Votre ville, ses coordonnées (à environ 10 km près) et votre fournisseur ne sont ajoutés que si vous cochez la case, et votre adresse IP jamais. Le code est open source sur GitHub.
