Dimension Core/Dash : Pays

Dimension : Pays (cc)

La dimension Pays segmente vos données de Real User Monitoring selon l'emplacement géographique du visiteur en utilisant les codes pays ISO. La performance n'est pas uniforme à travers le monde. Un site qui 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 jeu 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 les 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émentaires 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 contraintes physiques inévitables 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 a un impact direct sur le temps de chargement pour les images, les scripts et les polices.
• Qualité des appareils : Les régions à plus faibles revenus 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 ajoute aux délais réseau des délais de traitement qui gonflent l'INP.

Selon le Web Almanac 2025, seulement 48 % des origines mobiles passent les trois Core Web Vitals à l'échelle mondiale. Mais ce chiffre masque une énorme variance géographique. La Corée est en tête 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.

Lire les données par pays

Pays très 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 CDN de périphérie proches et des parcs d'appareils modernes. Dans les données CoreDash, le trafic européen et est-asiatique montre habituellement des valeurs p75 de LCP entre 1,5 s et 2,2 s.

Pays de niveau intermédiaire

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

Pays 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 LCP p75 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 réside dans l'infrastructure : mise en cache périphérique (edge caching), distribution 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 dotés de parcs d'appareils plus anciens (Inde, Asie du Sud-Est, certaines parties de l'Afrique) présentent un pire INP 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 décalages de mise en page sont causés par la logique de rendu, et non par les conditions du réseau. Si vous observez une variance du CLS selon le pays, vérifiez si vous servez des réseaux publicitaires, des bannières de cookies ou des scripts tiers différents selon la région.

Flux de travail de débogage

1. Triez par volume et impact : Ouvrez le tableau de la dimension Pays et triez par Impact. Votre pays à fort trafic ayant la pire performance est votre priorité absolue. Corriger la performance pour 40 % de vos utilisateurs vaut mieux que de la corriger pour 2 %.
2. Comparez avec votre carte CDN : Si un pays spécifique a un TTFB élevé, vérifiez si votre CDN y a un point de présence (PoP). L'absence de PoP signifie que les requêtes sont acheminées vers la périphérie disponible la plus proche, ajoutant de la latence.
3. Croisez avec le type d'appareil : Un pays avec un mauvais INP peut ne pas nécessiter d'optimisation JavaScript. Il se peut qu'il nécessite que vous serviez des pages plus légères aux appareils d'entrée de gamme dominant ce marché. Filtrez par Pays + Type d'appareil + Score de capacité du client pour confirmer.

Règle d'or de l'ingénierie

• Un TTFB inférieur à 800 ms pour chaque pays ciblé : Si un pays dépasse cette valeur, c'est un problème d'infrastructure. Ajoutez un PoP CDN ou un cache régional.
• Un LCP inférieur à 2,5 s pour vos 5 principaux pays en termes de trafic : Ce sont les marchés qui déterminent votre score CrUX agrégé et votre classement de recherche.
• N'optimisez pas pour la "moyenne mondiale" : Optimisez pour des pays spécifiques. Un p75 global de 2,3 s peut cacher le fait que l'Inde (votre deuxième marché le plus important) 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.