Un site qui se charge en une seconde depuis votre bureau peut en mettre quatre pour un visiteur à l’autre bout du monde. La distance, l’edge CDN qui répond, le DNS local et les scripts propres à chaque région modifient l’expérience de chaque marché, et un test de vitesse lancé depuis votre poste n’en montre rien. Si vous vendez ou cherchez à vous positionner dans plusieurs pays, tester depuis ces pays fait partie du suivi SEO, ce n’est pas une option facultative.
Ce guide explique comment tester la vitesse d’un site depuis différentes localisations : quels outils mesurent quoi, pourquoi PageSpeed Insights ne suffit pas à lui seul, comment vérifier que votre CDN se comporte de la même façon sur chaque marché, et un workflow simple à répéter chaque semaine.
Pourquoi la vitesse varie selon le pays
Une même URL ne correspond pas à la même page partout. Cinq éléments changent d’un marché à l’autre :
- La distance. Chaque aller-retour entre le visiteur et le serveur prend du temps, et une page en nécessite plusieurs (DNS, TCP, TLS, puis la requête). Les visiteurs éloignés paient ce coût à chaque fois.
- L’edge CDN. Un CDN répond depuis le point de présence le plus proche du visiteur, s’il en possède un dans la région. Un marché servi par un edge situé deux pays plus loin se comporte très différemment d’un marché disposant d’un edge local.
- L’état du cache. Chaque edge a son propre cache. Votre marché principal garde les pages au chaud ; un marché plus petit peut subir un cache miss et attendre votre serveur d’origine.
- Le routage DNS. Le geo DNS peut envoyer un pays vers une autre origine, voire vers un autre CDN.
- Le contenu propre à chaque région. Les bannières de consentement en Europe, les widgets de paiement locaux, les pages traduites et les tags tiers spécifiques à un pays ajoutent tous un poids que votre version principale ne charge jamais.
Les Core Web Vitals de Google sont mesurés sur des visites réelles : les marchés lents font donc baisser vos données terrain, même lorsque vos propres tests semblent parfaits.
Données lab et données terrain
Il existe deux types de données de vitesse, et vous avez besoin des deux.
Les données terrain proviennent de vrais utilisateurs de Chrome. PageSpeed Insights et Search Console les affichent à partir du Chrome UX Report (CrUX), mais uniquement sous la forme d’un chiffre global pour votre page ou votre origine. CrUX publie bien des données par pays dans son jeu de données public BigQuery, ce qui constitue la réponse la plus fiable à la question « quelle est notre vitesse au Brésil ? ». Ces données sont mensuelles et nécessitent un trafic suffisant depuis le pays concerné pour apparaître.
Les données lab proviennent d’un test contrôlé lancé à la demande. Le test Lighthouse intégré à PageSpeed Insights s’exécute depuis un data center Google, et non depuis les pays de vos visiteurs : son score lab ne dit donc rien de l’expérience sur un marché donné. Utilisez-le pour détecter les problèmes de la page elle-même, pas pour comparer les régions.
Pour des tests lab par localisation, utilisez un outil doté de vrais agents de test dans de nombreux endroits, comme WebPageTest, où vous choisissez la localisation, le navigateur et la vitesse de connexion pour chaque test. Les services commerciaux de monitoring synthétique font de même de façon planifiée.
Vérifier ce que reçoit chaque pays
Les outils de vitesse indiquent combien de temps une page a mis à se charger. Ils n’expliquent pas toujours pourquoi un pays est plus lent. Pour cela, vous devez voir la réponse que reçoit réellement un visiteur de ce pays : quel edge a répondu, s’il s’agissait d’un cache hit, s’il y a eu une redirection supplémentaire et quel était le poids de la page.
Les requêtes passant par des proxies résidentiels situés dans le pays ciblé montrent exactement cela, car la requête arrive depuis une connexion domestique de ce marché, comme celle d’un vrai visiteur. Les CDN et le geo DNS la routent comme ils routeraient vos clients.
Une simple vérification avec curl affiche le détail des temps et les en-têtes importants :
curl -s -o /dev/null -D - \
-x http://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 \
-w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total} size:%{size_download}\n" \
https://www.example.com/Remplacez country-de par chacun des marchés qui vous intéressent, par exemple country-br ou country-jp, puis comparez. Examinez :
- Les en-têtes de statut du cache, comme
cf-cache-status,x-cacheoux-vercel-cache. UnHITsur votre marché principal et unMISSailleurs signifient que cet edge sert des pages froides. - Les identifiants d’edge. L’en-tête
cf-rayde Cloudflare se termine par le code aéroport du data center qui a répondu ; CloudFront envoiex-amz-cf-pop; Fastly envoiex-served-by. Si les visiteurs allemands reçoivent une réponse depuis un autre continent, vous avez trouvé votre problème. Age, qui indique depuis combien de temps la copie en cache se trouve sur cet edge.- Les redirections et le poids. Une redirection propre à un pays ou une page localisée plus lourde se traduit par des sauts supplémentaires et davantage d’octets.
Une précaution : une requête passant par un proxy transite aussi par le réseau du proxy, ses temps absolus sont donc plus élevés que ceux d’un visiteur local. Utilisez les tests via proxy pour comparer les pays entre eux et voir ce qui est servi, et tirez les temps de chargement absolus de WebPageTest ou des données terrain. Pour un simple aperçu visuel d’une page depuis un autre pays, sans aucune configuration, un proxy web gratuit suffit.
Tester les performances du CDN et le cache des edges
La plupart des lenteurs régionales s’avèrent être un problème de CDN plutôt que de serveur. Effectuez ces vérifications pour chaque marché :
Couverture des edges. Vérifiez quel edge répond à chaque pays. Les fournisseurs publient la liste de leurs points de présence, mais la seule preuve est l’en-tête d’edge d’une requête émise depuis le pays lui-même, par exemple depuis l’Allemagne ou le Japon.
Taux de cache hit par région. Demandez la même URL deux ou trois fois depuis chaque pays. La première requête peut produire un miss ; la deuxième devrait produire un hit. Si les miss persistent, la réponse n’est probablement pas mise en cache dans cette région.
Fragmentation de la clé de cache. Un en-tête Vary portant sur les cookies ou le user agent, ou un cookie géographique défini lors de la première visite, peut scinder une page en de nombreuses entrées de cache. Les petits marchés ne tombent alors presque jamais sur une copie chaude.
Propagation des purges. Après un déploiement ou une purge, vérifiez depuis plusieurs pays que la nouvelle version est servie partout, et pas seulement sur l’edge le plus proche de vous.
Origin shield. Si les miss sont lents sur les marchés éloignés, un origin shield ou un cache hiérarchisé régional permet aux edges de récupérer le contenu depuis un cache proche plutôt que depuis votre origine.
Un workflow reproductible
- Choisissez vos marchés à partir de Search Console et de vos analytics : les pays qui génèrent du trafic ou du chiffre d’affaires, ainsi que ceux où vous cherchez à vous développer.
- Consultez les données terrain par pays dans le jeu de données CrUX sur BigQuery une fois par mois.
- Lancez des tests lab sur vos principaux templates depuis chaque marché dans WebPageTest, avec le même navigateur et la même connexion à chaque fois.
- Inspectez ce qui est servi grâce à des requêtes via proxy par pays : edge, statut du cache, redirections et poids.
- Corrigez et testez à nouveau sur les marchés où les chiffres ou les en-têtes semblent anormaux.
La même approche par pays s’applique aux positions et au contenu. Nos guides sur le suivi de positionnement en grille géographique et la QA de localisation à grande échelle couvrent ces vérifications.
FAQ
Comment tester la vitesse de mon site depuis un autre pays ?
Pour les temps de chargement, utilisez un outil lab doté d’agents de test dans ce pays, comme WebPageTest. Pour voir ce que reçoit ce pays (edge CDN, statut du cache, redirections), envoyez des requêtes via un proxy résidentiel situé sur place.
PageSpeed Insights teste-t-il depuis la localisation de mes visiteurs ?
Non. Son test lab s’exécute depuis un data center Google, et ses données terrain se résument à un chiffre global. Les données terrain par pays sont disponibles dans le jeu de données CrUX sur BigQuery.
Pourquoi mon site est-il plus lent dans certains pays ?
Généralement parce qu’il n’y a pas d’edge CDN à proximité, que l’edge a un cache froid, que le geo DNS envoie ce pays vers une origine éloignée ou que la page localisée charge des scripts supplémentaires.
À quelle fréquence tester la vitesse par pays ?
Des tests synthétiques hebdomadaires sur vos principaux templates, un examen mensuel des données terrain et une vérification supplémentaire après chaque déploiement majeur ou modification du CDN.
En résumé
La vitesse est une affaire locale. Utilisez les données terrain pour connaître la réalité de chaque pays, un outil lab multi-localisations pour obtenir des temps de chargement comparables, et des requêtes émises depuis le pays pour voir quel edge répond et s’il sert un cache chaud. La plupart des lenteurs régionales viennent du CDN, et elles se corrigent facilement dès que vous pouvez les observer depuis l’endroit où se trouvent vos visiteurs.