¿Cómo medimos la velocidad web?

En este texto descubrirás cómo descargamos y procesamos exactamente los datos de velocidad de los sitios web en el monitoreo de pagespeed.one.

Antes de continuar leyendo, asegúrate de estar familiarizado con las diferencias entre los distintos tipos de medición de velocidad (CrUX, synth y RUM) y de conocer los fundamentos de nuestro monitoreo de velocidad.

Datos de los usuarios de Google#

Recopilamos datos de las métricas Core Web Vitals (LCP, INP, CLS) del Chrome UX Report (CrUX) para mostrarlos en nuestros informes de la siguiente manera:

• En los test PLUS los descargamos y agregamos a los informes cada día en horas nocturnas. Esto se aplica tanto a los datos para el informe de Páginas como para el informe de Dominios y todas las apariciones de datos CrUX en toda la aplicación. Se aplica igualmente para móvil y escritorio.
• En las pruebas gratuitas, no descargamos datos para las páginas. Los datos para los dominios se descargan una vez cada dos días, alternando entre móvil y escritorio.

Los datos del Chrome UX Report se ven, por ejemplo, en el dashboard principal de tu equipo.

Los datos para los gráficos de evolución mensual de las métricas (en el informe de Dominios) se descargan una vez al mes. Los datos se publican cada segundo miércoles del mes y los procesamos en cuestión de días después.

Evolución de métricas en Chrome UX Report por meses, que mostramos en el informe de Dominios.

Datos sintéticos#

Obtenemos datos de pruebas sintéticas de Lighthouse de dos maneras:

• En los test PLUS ejecutamos Lighthouse en nuestra propia infraestructura varias veces al día. Detalles adicionales los encontrarás más abajo.
• En las pruebas gratuitas descargamos datos menos precisos del API PageSpeed Insights una vez cada dos días tanto para escritorio como para móvil.

Vamos a ver cómo realizamos las mediciones sintéticas en los test PLUS. Desde la versión 4.10 puedes realizar mediciones manuales (beta), configurar más tiempos de medición (beta) y el inicio de las pruebas es significativamente más rápido — detalles en el changelog del release 4.10.

Los datos sintéticos se recolectan a diario, por ejemplo, para el Vigilante de velocidad.

Mediciones sintéticas en los test PLUS#

🔐 Este tipo de medición la realizamos en los test PLUS.

Basándonos en nuestra experiencia con otras herramientas durante la consultoría de velocidad web y numerosos experimentos realizados durante el desarrollo del monitoreo, hemos llegado al siguiente método de prueba para cada URL.

Probamos en horas nocturnas, cinco veces seguidas y lo hacemos una vez al día.

Horas nocturnas#

Para la recolección de datos de métricas Core Web Vitals a corto plazo (días) y a más largo plazo (meses), consideramos que las horas nocturnas son la mejor práctica.

Por la noche, tus servidores no están sometidos a tanta carga, podemos probarlos con más tranquilidad y así observar la tendencia a largo plazo del desarrollo o deterioro de la velocidad. La velocidad de respuesta del servidor (métrica TTFB) influye en las métricas de usuario que observamos, como LCP o FCP.

Nuestra experiencia nos dice que los resultados nocturnos son mucho más estables y te dicen más sobre el desarrollo de las métricas en el tiempo.

Cinco veces seguidas#

Sabemos que las pruebas únicas, como las que realizamos con PageSpeed Insights en nuestras pruebas gratuitas, pueden arrojar resultados inexactos.

A través de la experimentación, hemos llegado a la necesidad de realizar cinco pruebas, lo que elimina la mayoría de las inexactitudes y maximiza la estabilidad de los números. Las pruebas se llevan a cabo con unos minutos de diferencia, los tiempos exactos siempre los ves en el detalle del test de Lighthouse.

Una vez al día#

Probamos cada URL estándar en el rango de unos minutos y estas pruebas se ejecutan siempre una vez al día, siempre durante la noche.

¿Por qué probamos tan «poco»?#

A veces recibimos la pregunta de por qué las pruebas se realizan solo en un corto período de tiempo diario. ¿Por qué no probamos sintéticamente cada minuto?

Aquí es bastante importante aclarar que nuestro monitoreo sirve para probar métricas de usuario de Core Web Vitals y otras. No se trata de un monitoreo de la disponibilidad del servidor ni de su carga. Para eso existen otras herramientas como Uptimerobot.com o Updown.io.

Además, las mediciones sintéticas no deben reemplazar los datos de los usuarios, que se utilizan para recopilar información precisa sobre el rendimiento del sitio web, no solo a lo largo de todos los horarios diarios, sino también a través de todos los demás segmentos de usuarios.

Para monitorear los cambios en los usuarios, recopilamos datos del Chrome UX Report y en sitios web más grandes implementamos SpeedCurve RUM.

¿En qué probamos y cómo está configurada la medición?#

Las pruebas se llevan a cabo en la infraestructura europea de Amazon Web Services (AWS), actualmente desde Frankfurt.

Seleccionamos cuidadosamente las máquinas de prueba para minimizar las fluctuaciones, especialmente en métricas de JavaScript como Total Blocking Time (TBT).

Aun así, es posible que ocasionalmente ocurran fluctuaciones causadas por la infraestructura de medición. En tal caso, informamos sobre estas situaciones y agregamos notas automáticas a los gráficos.

¿Y cómo está configurada la medición? A partir de octubre de 2024, la desaceleración de ambas mediciones es la siguiente:

Dispositivo	Descarga	Carga	RTT (tiempo de ida y vuelta)
Móvil	1,6 Mbit/s	0,75 Mbit/s	100 ms
Escritorio	10 Mbit/s	10 Mbit/s	40 ms

¿Qué URL realmente probamos?#

Las URL que ingresas en la configuración de la prueba pueden no ser idénticas a las URL que finalmente probamos. A esta URL la llamamos URL final.

¿Por qué se diferencian? Los servidores web comúnmente realizan redirecciones – por ejemplo, de example.com a www.example.com, de HTTP a HTTPS o agregan una barra al final de la dirección. Nuestra herramienta (la llamamos «redireccionador», más en el changelog del release 4.10) sigue estas redirecciones y encuentra la URL final real, en la que luego se realiza la prueba.

¿Dónde encuentras la URL final? La verás en los tooltips sobre los iconos de métricas en las tablas (bajo la descripción «URL probada») y en el detalle de la ejecución de la prueba.

¿Por qué la URL final puede diferir entre datos sintéticos y de usuarios? Cada fuente de datos devuelve la URL final de forma diferente:

• Lighthouse (synth)
  devuelve la URL en la que realmente terminó la prueba, después de todas las redirecciones. Esta URL generalmente coincide con la salida del redireccionador, incluidos los posibles parámetros de consulta.
• CrUX API (datos de usuario)
  devuelve la URL para la que tiene datos de usuario reales. Puede eliminar algunos parámetros de consulta si no tiene suficiente volumen de datos y realiza sus propias redirecciones.

Por eso puede suceder que en la tabla de datos de usuario (CrUX) veas una URL de prueba diferente que en la tabla de mediciones sintéticas (Lighthouse).

¿Cómo permitir que nuestro bot acceda a tu sitio web?#

Puede suceder que desees probar una versión no finalizada de tu sitio web o una vista previa (por ejemplo, beta, test, staging, pre-producción) que esté oculta detrás de alguna forma de protección.

A veces, las pruebas de velocidad no se logran ni siquiera en sitios web de producción. Nuestro robot de pruebas puede convertirse en «víctima» del bloqueo de robots en tu infraestructura.

Sin embargo, puedes permitir que nuestro robot acceda de una de estas dos maneras:

• Detecta el user-agent string. Nuestro robot contiene palabras como PageSpeed.ONE o Chrome-Lighthouse.
• Detecta la dirección IP. Nuestro robot viene de la dirección 18.192.177.19.

Si tu infraestructura utiliza un WAF (Web Application Firewall), es necesario agregar una nueva regla que evite el bloqueo en caso de acceso desde nuestra dirección IP, como se indica arriba. Esto puede ocurrir, por ejemplo, con Cloudflare, Azure o con otros proveedores.

¿Cómo medir sitios web con autenticación HTTP?#

La autenticación HTTP (a menudo en forma de HTTP Basic Auth) es una forma sencilla de proteger un sitio web que requiere un nombre de usuario y una contraseña al cargar la página.

Se utiliza principalmente para versiones de staging o desarrollo del sitio web y de la misma manera puedes usarla durante las pruebas sintéticas en el monitoreo PLUS.

Pero ten cuidado, un sitio web protegido con contraseña tiende a ser más lento. Debido al uso de la autenticación HTTP, puedes ver métricas TTFB, FCP o LCP hasta un 10% peores. Te explicaremos por qué.

¿Cómo configurar HTTP basic auth para la medición?#

Nuestras pruebas manejan la autenticación HTTP – basta con introducir la URL junto con las credenciales de acceso en el probador. El acceso funciona a través de Basic Auth estándar, tal como lo haría un navegador común.

En la configuración de la prueba añade las direcciones URL junto con las credenciales de acceso:

https://nombre:contraseña@test.example.com/url

Impacto en los resultados de la medición#

Los sitios web que operan en un entorno de staging a menudo tienen respuestas del servidor inestables. Generalmente, funcionan sin caché, sin CDN, a veces en modo de depuración. El resultado es un retraso en todas las métricas de velocidad de carga (TTFB, FCP, LCP).

La propia autenticación HTTP agrega, según nuestras mediciones, aproximadamente 450–500 ms de retraso adicional, nuevamente afectando las métricas de velocidad de carga.

El impacto de la autenticación HTTP lo puedes ver en los archivos HAR o Tracy en el detalle de la ejecución de la prueba en las fases Stalled o Request sent.

¿Cómo medir con mayor precisión en un servidor de staging?#

Si necesitas medir un entorno de staging o una versión no pública sin sesgos:

• usa una puerta trasera basada en la dirección IP, como se indicó anteriormente, o en el user-agent string, como se indicó anteriormente
• configura una excepción para nuestro bot, como se indicó anteriormente

De esta manera, obtendrás datos más puros que no están retrasados debido a la autenticación HTTP.

---

Prueba nuestro monitoreo de velocidad PLUS.