Dimension CoreDash : Pays

Dimension : Pays (cc)

La dimension Pays segmente vos données de Real User Monitoring en fonction de la situation géographique du visiteur à l'aide des codes pays ISO. La performance n'est pas uniforme à travers le globe. Un site qui se charge en 1,5 seconde aux Pays-Bas peut prendre 4 secondes au Brésil et 6 secondes en Inde. La dimension Pays transforme ce vague soupçon en un ensemble de données précis et filtrable.

Si vous servez des utilisateurs à l'international et que vous ne filtrez pas par pays, vous cachez vos pires performances derrière vos meilleures.

Pourquoi la géographie détermine la performance

Trois facteurs physiques font du pays le prédicteur le plus fort du TTFB et du LCP :

• Distance du serveur : Chaque tranche de 5 000 km supplémentaire entre l'utilisateur et votre serveur d'origine ajoute environ 30 à 50 ms de latence aller-retour. Si votre serveur se trouve à Francfort et votre utilisateur à Sydney, vous commencez avec plus de 250 ms de physique incontournable avant même qu'un seul octet ne soit servi.
• Infrastructure réseau : Les vitesses de connexion moyennes varient énormément. La Corée du Sud affiche une moyenne de plus de 200 Mbps, tandis que de nombreux pays d'Afrique et d'Asie du Sud se situent en dessous de 20 Mbps. Cela impacte directement le Load Time pour les images, les scripts et les polices.
• Qualité des appareils : Les régions à revenus plus faibles ont une proportion plus élevée d'appareils Android d'entrée de gamme. Ces téléphones ont des processeurs plus lents, moins de RAM et des versions de navigateur plus anciennes, ce qui aggrave les retards réseau par des retards de traitement qui gonflent l'INP.

Selon le 2025 Web Almanac, seulement 48 % des origines mobiles réussissent les trois Core Web Vitals à l'échelle mondiale. Mais ce chiffre masque d'énormes disparités géographiques. La Corée mène avec 39,3 % d'origines réussies, tandis que les pays dotés d'infrastructures moins développées tombent bien en dessous de la médiane mondiale.

Lecture des données par pays

Pays performants

Des pays comme les États-Unis, l'Allemagne, les Pays-Bas, le Japon et la Corée du Sud affichent généralement de solides Core Web Vitals. Ces régions combinent des réseaux rapides, des nœuds edge de CDN à proximité et des parcs d'appareils modernes. Dans les données CoreDash, le trafic européen et d'Asie de l'Est affiche généralement des valeurs de p75 LCP comprises entre 1,5 s et 2,2 s.

Pays de rang intermédiaire

Le Brésil, le Mexique, la Pologne, la Turquie et la Thaïlande se situent souvent dans la zone "à améliorer". Les vitesses de réseau sont décentes, mais la couverture CDN peut être plus limitée et le parc d'appareils comprend davantage de matériel de milieu de gamme. Attendez-vous à un p75 LCP compris entre 2,5 s et 3,5 s pour ces régions.

Pays aux conditions difficiles

L'Inde, l'Indonésie, le Nigeria, le Pakistan et les Philippines représentent certains des environnements de performance les plus difficiles. Une part élevée de trafic mobile (souvent plus de 85 %), des connexions moyennes plus lentes et des appareils d'entrée de gamme créent une triple contrainte. Un p75 LCP supérieur à 4 s est courant pour les sites sans optimisation agressive pour ces marchés.

Modèles géographiques spécifiques aux métriques

TTFB et LCP

Ce sont les métriques les plus affectées par la géographie. Si votre serveur d'origine se trouve dans une seule région et que vous n'utilisez pas de CDN, chaque pays en dehors de cette région paie une "taxe de latence". La solution est infrastructurelle : mise en cache edge, distribution par CDN et serveurs d'origine régionaux. Aucune optimisation frontend ne corrigera un TTFB de 300 ms causé par la distance.

INP

L'INP est davantage corrélé à la qualité de l'appareil qu'à la vitesse du réseau. Les pays disposant de parcs d'appareils plus anciens (Inde, Asie du Sud-Est, parties de l'Afrique) affichent un INP moins bon, même sur des réseaux rapides, car le goulot d'étranglement est le processeur, et non la bande passante. Filtrez par Pays + Type d'appareil pour séparer l'effet réseau de l'effet appareil.

CLS

Le CLS est largement indépendant de la géographie. Les changements de mise en page sont causés par la logique de rendu, et non par les conditions du réseau. Si vous constatez des variations de CLS par pays, vérifiez si vous servez des réseaux publicitaires, des bannières de consentement ou des scripts tiers différents par région.

Flux de travail de débogage

1. Trier par volume et impact : Ouvrez le tableau de la dimension Pays et triez par Impact. Votre pays à fort trafic affichant les pires performances est votre priorité absolue. Améliorer la performance pour 40 % de vos utilisateurs est plus efficace que de la corriger pour 2 %.
2. Comparer par rapport à votre carte CDN : Si un pays spécifique a un TTFB élevé, vérifiez si votre CDN y possède un point de présence (PoP). L'absence de PoP signifie que les requêtes sont acheminées vers l'edge disponible le plus proche, ce qui ajoute de la latence.
3. Croiser avec le type d'appareil : Un pays affichant un mauvais INP n'a peut-être pas besoin d'une optimisation JavaScript. Il nécessite peut-être que vous serviez des pages plus légères aux appareils d'entrée de gamme qui dominent ce marché. Filtrez par Pays + Type d'appareil + Client Capability Score pour confirmer.

Règle d'or en ingénierie

• TTFB inférieur à 800 ms pour chaque pays ciblé : Si un pays dépasse ce seuil, il s'agit d'un problème d'infrastructure. Ajoutez un PoP de CDN ou un cache régional.
• LCP inférieur à 2,5 s pour vos 5 pays principaux en termes de trafic : Ce sont les marchés qui déterminent votre score CrUX agrégé et votre classement dans les recherches.
• Ne pas optimiser pour une "moyenne mondiale" : Optimisez pour des pays spécifiques. Un p75 mondial de 2,3 s peut masquer le fait que l'Inde (votre deuxième marché) se situe à 4,1 s.

La dimension Pays est votre outil d'audit d'infrastructure. Elle vous indique exactement où votre CDN, votre stratégie de mise en cache et le placement de vos serveurs font défaut aux utilisateurs réels.