Depuis chez vous, Google Cloud est-il rapide ?

La plupart des sites de « ping cloud » et tous les looking glass des fournisseurs mesurent depuis leurs serveurs, installés en centre de données sur un transit haut de gamme. Ça vous dit à quelle vitesse un centre de données en joint un autre. Rien sur ce que vous ressentez vraiment : votre box ou votre mobile, le réseau de votre FAI, ses sorties internationales et leur encombrement ce soir.

Me2Cloud envoie chaque requête depuis votre navigateur : le résultat inclut tout, Wi‑Fi, box, FAI, la route choisie par votre FAI et l’heure de pointe.

1. Une requête de préchauffage ouvre DNS, TCP et TLS. Son temps est affiché mais jamais compté.
2. Ensuite le navigateur envoie 5, 10 ou 20 requêtes au même hôte sur la même connexion. Chacune coûte un aller-retour plus le temps de traitement du fournisseur.
3. Chaque fournisseur utilise le type de requête dont nous avons vérifié qu’il garde la connexion ouverte : GET pour AWS, Azure, Google Cloud, Huawei Cloud, DigitalOcean et Scaleway ; HEAD pour Oracle, IBM Cloud, Alibaba Cloud, Tencent Cloud, Volcengine, Baidu AI Cloud, Naver Cloud, Linode, Vultr et OVHcloud (leur GET ferme la connexion et triplerait chaque mesure) ; <img> seulement pour Hetzner.
4. Nous donnons la médiane (la valeur typique), la moyenne, le P90 (9 mesures sur 10 en dessous), la gigue (écart moyen entre deux mesures consécutives) et la perte (mesures sans réponse dans le délai).
5. Le niveau vient de la médiane : T0 ≤ 30 ms, T1 ≤ 80 ms, T2 ≤ 150 ms, T3 ≤ 250 ms, T4 au-delà. Le score des recommandations est médiane + 2 × gigue + pénalité de perte : 60 ms réguliers battent 45 ms en dents de scie.

• Le même chemin que votre trafic. Sites, API, tunnels sur le port 443, connexions aux jeux et téléchargements passent par TCP. Beaucoup de FAI mettent l’ICMP dans une file à part, le limitent ou le routent autrement : le ping peut sembler bon alors que les pages rament, ou l’inverse.
• Pas étouffé par les limitations. Box et clouds limitent ou jettent souvent l’ICMP. Un point de terminaison HTTPS public répond toujours.
• Votre vraie configuration compte. DNS, choix IPv4/IPv6, proxies et accélérateurs s’appliquent au trafic du navigateur : vous mesurez ce que vous obtiendriez réellement.
• La contrepartie : chaque mesure inclut aussi un petit temps de traitement serveur, assez constant. Nous avons mesuré 0–5 ms chez AWS, environ 8 ms chez Alibaba Cloud et environ 20 ms chez Huawei Cloud OBS. Au-delà de 100 ms, c’est négligeable ; pour des régions très proches, le chiffre est un peu plus élevé que le ping.

• Les réseaux grand public sont surtout chargés de 20:00 à 23:00, et les liaisons internationales encore plus. Une région T1 à midi peut tomber en PNJ le soir.
• Testez une fois en journée et une fois à l’heure de pointe. Les tests enregistrés portent la mention « heure de pointe » et se comparent dans les Résultats.
• Mettez en pause gros téléchargements, streaming et synchronisations pendant le test. Le câble vaut mieux que le Wi‑Fi ; en Wi‑Fi, restez près de la box.
• En données mobiles, le résultat varie avec le signal. Testez là où vous utiliserez vraiment le service.

• Présélectionner des régions avant de prendre un serveur, un serveur de jeu ou une origine de CDN.
• Comparer les régions d’un même fournisseur, ou la même ville chez plusieurs fournisseurs.
• Vérifier la stabilité (gigue, perte) pour le jeu, la visio, le bureau à distance et SSH.
• Voir ce que valent vraiment votre proxy, votre accélérateur ou votre nouvelle offre, en testant avec et sans.
• Tester votre propre serveur ou CDN à côté des grands noms grâce à une cible personnalisée.

• Un seul endroit. C’est votre ligne, pas celle de vos utilisateurs. Demandez à quelques-uns de lancer le test, ou exportez et comparez.
• Des cibles, pas votre future VM. Nous testons le point de terminaison public d’API ou de stockage de chaque fournisseur dans la région. Les serveurs d’une même région partagent généralement le réseau, mais les routes premium (par exemple CN2, BGP ou mono-opérateur, Lightsail ou EC2) peuvent différer.
• Ni débit, ni UDP, ni traceroute. On mesure des allers-retours, pas la vitesse de téléchargement, le trafic UDP des jeux ou les sauts intermédiaires.
• Effets du navigateur. Extensions, proxies, VPN et onglets lourds ajoutent du bruit. Fermez les onglets lourds et gardez cette page au premier plan.
• Hetzner ne peut pas garder une connexion ouverte depuis un navigateur : ses chiffres incluent une négociation à chaque fois. Certaines cibles peuvent être injoignables depuis quelques pays.

• La page n’est faite que de fichiers statiques sur Cloudflare. Pas de serveur, pas de compte, pas d’analytique, et les résultats ne sont jamais envoyés.
• Toutes les requêtes de test vont directement de votre navigateur au fournisseur. Ouvrez le Journal des requêtes ou les outils de développement (onglet Réseau) pour les voir une à une.
• Les infos réseau viennent de Cloudflare (speed.cloudflare.com/meta et /cdn-cgi/trace), et la vérification WebRTC facultative demande à stun.cloudflare.com votre adresse de sortie UDP. Désactivable dans les Réglages.
• Réglages, cibles personnalisées et derniers tests restent dans le stockage local de ce navigateur ; « Effacer les données de test » supprime les résultats.

Solliciter trop fort les points de terminaison publics pourrait déclencher la limitation ou le WAF d’un fournisseur et fausser le résultat. Le test reste très en dessous :

• Une requête à la fois par hôte, avec une pause de 250–370 ms entre les mesures (2–3 requêtes par seconde et par hôte au maximum).
• Au plus 2 hôtes par fournisseur en même temps, et 8 au total (4 par défaut).
• Au plus 21 requêtes par hôte et par test (préchauffage + 20). Pas de mode continu.
• Un hôte est abandonné après 3 échecs d’affilée au lieu d’être relancé.
• Des requêtes « simples » anonymes, sans cookie ni référent : pas de prévol, réponses minuscules (quelques centaines d’octets), HEAD dès que possible, aucun gros téléchargement.

C’est moins de trafic que l’ouverture d’une page web ordinaire. Chaque cible a été vérifiée : elle répond normalement aux requêtes anonymes (200, 403 ou 404, peu importe pour la mesure).

Si votre trafic passe par un proxy, le navigateur mesure votre route vers le proxy plus celle du proxy vers le fournisseur, pas votre propre ligne. Le panneau réseau cherche les signes habituels : un réseau de sortie de centre de données, un fuseau horaire qui ne correspond pas au pays de sortie, WARP, ou une sortie WebRTC différente de la sortie HTTPS.

Utilisez Règles de connexion directe pour n’envoyer en direct que les hôtes de test (Clash / Mihomo, Surge, Shadowrocket, Quantumult X, Loon, sing-box, Xray, SwitchyOmega ou liste simple), puis revérifiez. Si c’est le proxy lui-même que vous voulez mesurer, laissez-le actif : les chiffres seront ses vraies performances.

• La bande de chaque ligne utilise une échelle commune (logarithmique, de 2 ms à 3 s). Les points sont les mesures, la zone ombrée couvre la moitié centrale des mesures et le trait est la médiane.
• Zone étroite, c’est stable ; zone large ou points dispersés, c’est de la gigue. Une × rouge compte les mesures perdues.
• Cliquez sur une ligne pour voir chaque mesure dans l’ordre, toutes les statistiques et la cible utilisée. ✓ signale ce qui correspond à vos besoins.