Cómo medir bien la velocidad de una web

Para medir bien la velocidad de una web, combina dos tipos de datos: las pruebas de laboratorio, que cargan tu página en condiciones controladas y te ayudan a depurar, y los datos de campo, que muestran lo rápida que es tu web de verdad para los visitantes reales. Usa las mismas herramientas, páginas y ajustes antes y después de cada cambio, repite cada prueba varias veces y valora el resultado por medianas y datos de usuarios reales, no por una única puntuación. Esta guía explica qué herramienta usar para cada cosa y cómo hacer una comparación de antes y después en la que puedas confiar.

Datos de laboratorio frente a datos de campo

Casi toda la confusión sobre la velocidad de una web viene de mezclar estos dos tipos de datos.

Los datos de laboratorio salen de una prueba ejecutada en un dispositivo, con un perfil de red y desde una ubicación. Lighthouse es el ejemplo más conocido. Está detrás de los datos de PageSpeed Insights de Google, que usa corewebvitals.page, y viene integrado en Chrome DevTools. Las pruebas de laboratorio se pueden repetir y dan diagnósticos detallados, así que son ideales para encontrar causas y comprobar si una solución funciona. Pero son una simulación: una visita, con un perfil de limitación concreto, desde donde se ejecute la prueba.

Los datos de campo, también llamados monitorización de usuarios reales (RUM), vienen de visitantes reales con sus propios móviles, portátiles y redes. Google los recoge de los usuarios de Chrome en el Chrome UX Report (CrUX). Los ves en Search Console, y herramientas como corewebvitals.page los muestran para cualquier URL. Los datos de campo son los que usa Google para evaluar la experiencia de página y reflejan la realidad, incluidos los dispositivos lentos y los visitantes lejanos. Su inconveniente es lo que tardan en reflejar los cambios: CrUX informa sobre una ventana móvil de 28 días, así que un cambio que hagas hoy tarda semanas en verse del todo.

Usa los datos de laboratorio para trabajar y los de campo para decidir si el trabajo ha merecido la pena.

La herramienta adecuada para cada tarea

No necesitas una gran caja de herramientas. Con cuatro cubres casi todo.

corewebvitals.page

corewebvitals.page muestra los dos tipos de datos para móvil y escritorio a partir de los datos de PageSpeed Insights de Google: datos de campo de CrUX de los últimos 28 días, si tu web tiene tráfico suficiente, y una ejecución de laboratorio de Lighthouse. Lee primero los datos de campo. La puntuación de rendimiento de 0 a 100 pertenece solo a la parte de laboratorio y no es lo que usa Google para el posicionamiento.

Search Console

El informe de Core Web Vitals de Google Search Console agrupa tus URLs por estado (buenas, necesitan mejorar, malas) a partir de los datos de campo. Es el mejor sitio para ver qué plantillas de página tienen problemas en toda la web, en lugar de probar las URLs de una en una.

Chrome DevTools

Los paneles Performance y Network muestran exactamente qué pasa durante una carga: qué petición bloquea el renderizado, qué script ocupa el hilo principal, cuánto tarda el servidor en responder. El panel Lighthouse ejecuta en local el mismo tipo de prueba de laboratorio. Usa una ventana de incógnito para que las extensiones del navegador no distorsionen los resultados.

Comprobaciones desde la línea de comandos

Para el tiempo de respuesta del servidor, curl te da una cifra limpia y repetible sin nada del peso del navegador:

for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/
done

Esto muestra el tiempo hasta el primer byte de cinco peticiones seguidas. Es especialmente útil para comprobar cambios en la caché y en el servidor. La guía para reducir el TTFB explica cómo desglosar más esa cifra.

Qué métricas mirar

Céntrate en unas pocas métricas que describen lo que viven los visitantes:

• Largest Contentful Paint (LCP): cuándo aparece el contenido principal. Lo bueno es 2,5 s o menos.
• Interaction to Next Paint (INP): lo rápido que reacciona la página a clics y toques. Lo bueno es 200 ms o menos. Solo se puede medir con datos de campo.
• Cumulative Layout Shift (CLS): cuánto salta el diseño. Lo bueno es 0,1 o menos.
• Time to First Byte (TTFB): lo rápido que empieza a responder el servidor. web.dev recomienda 0,8 s o menos.

Google evalúa las tres Core Web Vitals (en inglés) en el percentil 75 de las cargas de página, por separado para móvil y escritorio. Es decir, tres de cada cuatro visitas deberían alcanzar el umbral. La guía sobre las Core Web Vitals explica qué influye en cada métrica y cómo mejorarla.

El peso total de la página y el tiempo de "carga completa" son menos útiles de lo que parecen. Una página puede terminar de cargar tarde por culpa de un widget de chat en el que nadie se fija, mientras que una imagen principal lenta, que todo el mundo nota, apenas afecta al tiempo total de carga.

Por qué tus resultados cambian tanto

Si ejecutas la misma prueba de laboratorio tres veces y obtienes tres puntuaciones distintas, no hay nada roto. Motivos habituales:

• Caché fría frente a caché caliente. La primera petición después de un despliegue o de vaciar la caché suele ser mucho más lenta que las siguientes, en tu servidor y en cualquier CDN.
• Carga del servidor. Una prueba en horas punta compite con los visitantes reales.
• Scripts de terceros. Los anuncios, los gestores de etiquetas y los widgets de chat cargan contenido distinto cada vez.
• Ubicación de la prueba. Las pruebas de laboratorio basadas en los datos de PageSpeed Insights de Google, incluidas las de corewebvitals.page, se ejecutan desde un centro de datos de Google. Si tu servidor está en otro continente, la prueba mide esa distancia.
• La máquina de prueba. Lighthouse en DevTools depende de la CPU de tu propio ordenador y de todo lo que esté ejecutando en ese momento.

Una comparación de antes y después fiable

Cuando cambies algo, como la configuración de caché, un tema nuevo o un CDN, sigue una rutina fija para que la comparación sea justa.

1. Elige páginas representativas. Coge una de cada plantilla importante: portada, página de categoría o listado, ficha de producto o artículo. Incluye tu landing page más visitada.
2. Apunta las condiciones. La misma herramienta, el mismo perfil de dispositivo (móvil y escritorio por separado), la misma ubicación de prueba y, si puedes, la misma hora del día.
3. Calienta y luego mide. Carga cada página una vez y descarta ese resultado, salvo que quieras medir expresamente el rendimiento de la primera visita. Después ejecuta al menos cinco pruebas por página.
4. Usa la mediana. Quédate con el valor central de tus ejecuciones, no con el mejor. Anota el LCP, el CLS, el TTFB y el Total Blocking Time de las pruebas de laboratorio.
5. Cambia una sola cosa cada vez. Si cambias de hosting y de tema a la vez, no sabrás cuál de los dos ha ayudado.
6. Repite exactamente la misma rutina después del cambio. Compara las medianas página a página.
7. Confírmalo con datos de campo. Revisa los datos de campo en corewebvitals.page y en Search Console durante las semanas siguientes. Las mejoras de laboratorio que no aparecen para los usuarios reales no son mejoras reales.

Si usas un CDN o una caché en el edge, comprueba que la página probada se sirvió realmente desde la caché durante las pruebas del "después". Si no, estás midiendo tu origen y no el cambio.

Cómo te ayuda fast.site

fast.site se coloca delante de tu hosting actual como una red edge con caché, optimización de imágenes y seguridad. Mantienes tu proveedor y apuntas los servidores de nombres de tu dominio a fast.site; tras la verificación, las peticiones se sirven a través del edge.

Para medir, importan dos cosas. La primera: cada respuesta lleva cabeceras que te dicen qué ha pasado. fs-cache muestra HIT, MISS o BYPASS, y fs-cache-age y fs-cache-hits indican desde hace cuánto y cuántas veces se ha usado la copia en caché. Así es fácil confirmar que tu prueba del "después" salió de verdad de la caché. El artículo sobre cómo comprobar la caché explica cómo hacerlo.

La segunda: la analítica del panel informa de las peticiones, la tasa de aciertos de caché, el ancho de banda servido desde el edge frente al origen, el TTFB y las tasas de error de tu propio tráfico. Junto con los datos de campo de corewebvitals.page, eso te da una visión de antes y después basada en tus visitantes reales y no en una sola prueba.

La mejor forma de valorar el efecto es medirlo en tu propia web con la rutina anterior. Puedes hacerlo, por ejemplo, durante una prueba gratuita de 7 días. Los planes y el tráfico incluido están en la página de precios.

Preguntas frecuentes

¿Por qué mi puntuación de PageSpeed cambia cada vez?

La puntuación de rendimiento sale de una única ejecución de laboratorio, en la que influyen la carga del servidor, el estado de la caché, los scripts de terceros y las variaciones de la red. Las pequeñas diferencias entre ejecuciones son normales. Haz varias pruebas, usa la mediana y fíate de la sección de datos de campo para ver la situación real.

¿Hace falta sacar un 100 en PageSpeed?

No. La puntuación es un resumen de laboratorio y no se usa como señal de posicionamiento. Lo que importa es si los visitantes reales tienen unas buenas Core Web Vitals, algo que ves en los datos de campo. Perseguir los últimos puntos suele costar mucho esfuerzo sin ninguna diferencia apreciable.

¿Por qué no hay datos de campo de mi web?

CrUX solo publica datos cuando una URL o un origen tiene suficientes visitas de usuarios de Chrome en los últimos 28 días. Las webs pequeñas o las páginas nuevas a menudo no llegan a ese umbral. En ese caso, apóyate en las pruebas de laboratorio y en tu propia monitorización hasta que haya datos suficientes.

¿Cuánto tardan las mejoras en verse en Search Console?

Los datos de campo se recogen en una ventana móvil de 28 días, así que una mejora aparece poco a poco y solo se ve del todo al cabo de unas cuatro semanas. Search Console puede tardar algo más en volver a validar las URLs agrupadas. Las pruebas de laboratorio muestran el efecto al momento, y por eso las usas primero para verificar una solución.

¿Debo probar en móvil o en escritorio?

En los dos, por separado. Google los evalúa por separado, y los resultados en móvil suelen ser peores por las CPU y las redes más lentas. Si solo tienes tiempo para uno, empieza por el móvil.