Dimensión de Core/Dash: País

Dimensión: País (cc)

La dimensión País segmenta sus datos de Real User Monitoring según la ubicación geográfica del visitante utilizando códigos de país ISO. El rendimiento no es uniforme en todo el mundo. Un sitio que carga en 1,5 segundos en los Países Bajos puede tardar 4 segundos en Brasil y 6 segundos en la India. La dimensión País convierte esa vaga sospecha en un conjunto de datos preciso y filtrable.

Si atiende a usuarios a nivel internacional y no está filtrando por país, está ocultando su peor rendimiento detrás del mejor.

Por qué la geografía determina el rendimiento

Tres factores físicos hacen del país el predictor más fuerte del TTFB y el LCP:

• Distancia del servidor: Cada 5.000 km adicionales entre el usuario y su servidor de origen añade aproximadamente entre 30 y 50 ms de latencia de ida y vuelta. Si su servidor se encuentra en Frankfurt y su usuario en Sídney, está empezando con más de 250 ms de física inevitable antes de que se sirva un solo byte.
• Infraestructura de red: Las velocidades medias de conexión varían enormemente. Corea del Sur promedia más de 200 Mbps, mientras que muchos países de África y el sur de Asia se sitúan por debajo de los 20 Mbps. Esto impacta directamente en el tiempo de carga de imágenes, scripts y fuentes.
• Calidad del dispositivo: Las regiones de menores ingresos tienen una mayor proporción de dispositivos Android económicos. Estos teléfonos tienen CPU más lentas, menos RAM y versiones de navegador más antiguas, agravando los retrasos de red con retrasos de procesamiento que inflan el INP.

Según el Web Almanac 2025, solo el 48% de los orígenes móviles aprueban los tres Core Web Vitals a nivel global. Pero ese número enmascara una enorme variación geográfica. Corea lidera con un 39,3% de orígenes aprobados, mientras que los países con infraestructuras menos desarrolladas caen muy por debajo de la media global.

Lectura de los datos por país

Países de alto rendimiento

Países como Estados Unidos, Alemania, Países Bajos, Japón y Corea del Sur suelen mostrar unos Core Web Vitals sólidos. Estas regiones combinan redes rápidas, nodos periféricos (edge) de CDN cercanos y flotas de dispositivos modernos. En los datos de CoreDash, el tráfico europeo y del este asiático suele mostrar valores p75 de LCP de entre 1,5 s y 2,2 s.

Países de nivel medio

Brasil, México, Polonia, Turquía y Tailandia a menudo se sitúan en el rango de "necesita mejora". Las velocidades de red son decentes, pero la cobertura de la CDN puede ser menor, y la combinación de dispositivos incluye más hardware de gama media. Espere un p75 de LCP de entre 2,5 s y 3,5 s para estas regiones.

Países con desafíos

India, Indonesia, Nigeria, Pakistán y Filipinas representan algunos de los entornos de rendimiento más difíciles. Una alta cuota de tráfico móvil (a menudo superior al 85%), conexiones medias más lentas y dispositivos económicos crean una triple restricción. Un p75 de LCP superior a 4 s es común en sitios sin una optimización agresiva para estos mercados.

Patrones geográficos específicos de cada métrica

TTFB y LCP

Estas son las métricas más afectadas por la geografía. Si su servidor de origen está en una sola región y no utiliza una CDN, cada país fuera de esa región paga un impuesto de latencia. La solución es la infraestructura: almacenamiento en caché perimetral (edge caching), distribución CDN y servidores de origen regionales. Ninguna cantidad de optimización frontend soluciona un TTFB de 300 ms causado por la distancia.

INP

El INP se correlaciona más con la calidad del dispositivo que con la velocidad de la red. Países con flotas de dispositivos más antiguas (India, el sudeste asiático, partes de África) muestran un peor INP incluso en redes rápidas porque el cuello de botella es la CPU, no el ancho de banda. Filtre por País + Tipo de dispositivo para separar el efecto de la red del efecto del dispositivo.

CLS

El CLS es en gran medida independiente de la geografía. Los cambios de diseño son causados por la lógica de renderizado, no por las condiciones de la red. Si observa variaciones en el CLS por país, investigue si está sirviendo diferentes redes publicitarias, banners de cookies o scripts de terceros según la región.

Flujo de trabajo de depuración

1. Ordene por volumen e impacto: Abra la tabla de la dimensión País y ordene por Impacto. Su país con mayor tráfico y peor rendimiento es su principal prioridad. Arreglar el rendimiento para el 40% de sus usuarios es mejor que arreglarlo para el 2%.
2. Compare con su mapa de CDN: Si un país específico tiene un alto TTFB, compruebe si su CDN tiene un Punto de Presencia (PoP) allí. La falta de PoPs significa que las solicitudes se enrutan al nodo perimetral disponible más cercano, lo que añade latencia.
3. Realice referencias cruzadas con el Tipo de Dispositivo: Un país con un mal INP puede no necesitar optimización de JavaScript. Puede que necesite servir páginas más ligeras a los dispositivos económicos que dominan ese mercado. Filtre por País + Tipo de dispositivo + Puntuación de capacidad del cliente para confirmarlo.

Regla general de ingeniería

• TTFB por debajo de 800 ms para cada país al que se dirija: Si un país supera esto, es un problema de infraestructura. Añada un PoP de CDN o una caché regional.
• LCP por debajo de 2,5 s para sus 5 principales países por tráfico: Estos son los mercados que determinan su puntuación agregada de CrUX y su posicionamiento en las búsquedas.
• No optimice para el "promedio global": Optimice para países específicos. Un p75 global de 2,3 s puede ocultar el hecho de que la India (su segundo mercado más grande) se sitúe en 4,1 s.

La dimensión País es su herramienta de auditoría de infraestructura. Le dice exactamente dónde su CDN, estrategia de almacenamiento en caché y ubicación del servidor están fallando a los usuarios reales.