Cómo probar la velocidad de un sitio web desde distintos países

Un sitio que carga en un segundo desde tu oficina puede tardar cuatro segundos para un visitante al otro lado del mundo. La distancia, el edge de la CDN que responde, el DNS local y los scripts específicos de cada región cambian la experiencia de cada mercado, y una sola prueba de velocidad desde tu propia mesa no muestra nada de eso. Si vendes o posicionas en varios países, hacer pruebas desde esos países forma parte de la monitorización SEO, no es un extra opcional.

Esta guía explica cómo probar la velocidad de un sitio web desde distintas ubicaciones: qué mide cada herramienta, por qué PageSpeed Insights por sí solo no basta, cómo comprobar que tu CDN se comporta igual en todos los mercados y un flujo de trabajo sencillo que puedes repetir cada semana.

Por qué la velocidad cambia según el país

La misma URL no es la misma página en todas partes. Hay cinco factores que cambian entre mercados:

• Distancia. Cada viaje de ida y vuelta entre el visitante y el servidor cuesta tiempo, y una página necesita varios (DNS, TCP, TLS y después la petición). Los visitantes lejanos pagan ese coste en cada uno de ellos.
• El edge de la CDN. Una CDN responde desde el punto de presencia más cercano al visitante, si tiene uno en esa región. Un mercado atendido desde un edge situado dos países más allá se comporta de forma muy distinta a uno con un edge local.
• Estado de la caché. Cada edge tiene su propia caché. Tu mercado principal mantiene las páginas en caché; un mercado más pequeño puede sufrir un fallo de caché y esperar a tu origen.
• Enrutamiento DNS. El geo DNS puede enviar un país a otro origen o incluso a otra CDN.
• Contenido específico por región. Los banners de consentimiento en Europa, los widgets de pago locales, las páginas traducidas y las etiquetas de terceros propias de cada país añaden un peso que tu versión principal nunca carga.

Las Core Web Vitals de Google se miden con visitas reales, así que los mercados lentos empeoran tus datos de campo aunque tus propias pruebas parezcan perfectas.

Datos de laboratorio frente a datos de campo

Hay dos tipos de datos de velocidad, y necesitas ambos.

Los datos de campo proceden de usuarios reales de Chrome. PageSpeed Insights y Search Console los muestran a partir del Chrome UX Report (CrUX), pero solo como una cifra global para tu página u origen. CrUX sí publica datos por país en su conjunto de datos público de BigQuery, que es la respuesta más fiable a “¿qué velocidad tenemos en Brasil?”. Es mensual y requiere suficiente tráfico de ese país para aparecer.

Los datos de laboratorio proceden de una prueba controlada que se ejecuta cuando quieras. La prueba de Lighthouse dentro de PageSpeed Insights se ejecuta desde un centro de datos de Google, no desde los países de tus visitantes, así que su puntuación de laboratorio no dice nada sobre la experiencia en un mercado concreto. Úsala para encontrar problemas en la propia página, no para comparar regiones.

Para pruebas de laboratorio por ubicación, usa una herramienta con agentes de prueba reales en muchos lugares, como WebPageTest, donde eliges la ubicación, el navegador y la velocidad de conexión de cada ejecución. Los servicios comerciales de monitorización sintética hacen lo mismo de forma programada.

Comprueba qué se sirve en cada país

Las herramientas de velocidad te dicen cuánto tardó una página. No siempre te dicen por qué un país va más lento. Para eso necesitas ver la respuesta que recibe realmente un visitante de ese país: qué edge respondió, si hubo acierto de caché, si hubo una redirección adicional y cuánto pesaba la página.

Las peticiones a través de proxies residenciales en el país objetivo muestran exactamente eso, porque la petición llega desde una conexión doméstica de ese mercado, igual que la de un visitante real. Las CDN y el geo DNS la enrutan como enrutarían a tus clientes.

Una comprobación sencilla con curl imprime el desglose de tiempos y las cabeceras que importan:

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/

Cambia country-de por cada mercado que te interese, por ejemplo country-br o country-jp, y compara. Fíjate en:

• Cabeceras de estado de caché como cf-cache-status, x-cache o x-vercel-cache. HIT en tu mercado principal y MISS en otros significa que ese edge sirve páginas sin caché.
• Identificadores del edge. El cf-ray de Cloudflare termina con el código de aeropuerto del centro de datos que respondió; CloudFront envía x-amz-cf-pop; Fastly envía x-served-by. Si a los visitantes alemanes les responde un edge de otro continente, has encontrado el problema.
• Age, que indica cuánto tiempo lleva la copia en caché en ese edge.
• Redirecciones y tamaño. Una redirección específica del país o una página localizada más pesada se traduce en saltos adicionales y más bytes.

Una advertencia: una petición a través de proxy también recorre la red del proxy, así que sus tiempos absolutos son más altos que los de un visitante local. Usa las pruebas con proxy para comparar países entre sí y para ver qué se sirve, y toma los tiempos de carga absolutos de WebPageTest o de los datos de campo. Para echar un vistazo rápido a una página desde otro país sin ninguna configuración, basta con un proxy web gratuito.

Cómo probar el rendimiento de la CDN y la caché en el edge

La mayor parte de la lentitud regional resulta ser un problema de la CDN más que del servidor. Haz estas comprobaciones en cada mercado:

Cobertura de edges. Confirma qué edge responde a cada país. Los proveedores publican sus listas de puntos de presencia, pero la única prueba real es la cabecera del edge en una petición hecha desde dentro de ese país, por ejemplo desde Alemania o Japón.

Tasa de aciertos de caché por región. Solicita la misma URL dos o tres veces desde cada país. La primera petición puede fallar; la segunda debería acertar. Si sigue fallando, probablemente la respuesta no se puede almacenar en caché allí.

Fragmentación de la clave de caché. Una cabecera Vary basada en cookies o en el user agent, o una cookie geográfica fijada en la primera visita, puede dividir una página en muchas entradas de caché. Los mercados pequeños casi nunca encuentran entonces una copia en caché.

Propagación de purgas. Tras un despliegue o una purga, comprueba desde varios países que la nueva versión se sirve en todas partes, no solo en el edge más cercano a ti.

Origin shield. Si los fallos de caché son lentos en mercados lejanos, un origin shield o una caché escalonada regional permite que los edges obtengan el contenido de una caché cercana en lugar de tu origen.

Un flujo de trabajo repetible

1. Elige tus mercados a partir de Search Console y de tu analítica: los países que generan tráfico o ingresos, más aquellos en los que intentas crecer.
2. Revisa los datos de campo por país en el conjunto de datos de CrUX en BigQuery una vez al mes.
3. Ejecuta pruebas de laboratorio de tus plantillas clave desde cada mercado en WebPageTest, con el mismo navegador y la misma conexión cada vez.
4. Inspecciona qué se sirve con peticiones a través de proxy por país: edge, estado de caché, redirecciones y tamaño.
5. Corrige y vuelve a probar en los mercados donde las cifras o las cabeceras no cuadren.

El mismo enfoque por país se aplica a los rankings y al contenido. Nuestras guías sobre seguimiento de rankings con geo-grid y QA de localización a escala cubren esas comprobaciones.

Preguntas frecuentes

¿Cómo pruebo la velocidad de mi sitio web desde otro país?

Usa una herramienta de laboratorio con agentes de prueba en ese país, como WebPageTest, para los tiempos de carga. Para ver qué se sirve en ese país (edge de la CDN, estado de caché, redirecciones), envía peticiones a través de un proxy residencial situado allí.

¿PageSpeed Insights hace las pruebas desde la ubicación de mis visitantes?

No. Su prueba de laboratorio se ejecuta desde un centro de datos de Google y sus datos de campo son una única cifra global. Los datos de campo por país están disponibles en el conjunto de datos de CrUX en BigQuery.

¿Por qué mi sitio es más lento en algunos países?

Normalmente porque no hay un edge de la CDN cercano, el edge tiene la caché vacía, el geo DNS envía ese país a un origen lejano o la página localizada carga scripts adicionales.

¿Con qué frecuencia debo probar la velocidad por país?

Comprobaciones sintéticas semanales de tus plantillas clave, una revisión mensual de los datos de campo y una comprobación adicional después de cada despliegue importante o cambio en la CDN.

En resumen

La velocidad es local. Usa los datos de campo para conocer la realidad de cada país, una herramienta de laboratorio con varias ubicaciones para obtener tiempos de carga comparables y peticiones desde dentro de cada país para ver qué edge responde y si sirve desde una caché activa. La mayor parte de la lentitud regional se debe a la CDN, y es fácil de corregir en cuanto puedes verla desde donde están tus visitantes.