Dos páginas pueden sacar la misma nota en una prueba de velocidad y rendir de forma muy distinta para visitantes reales. Hacer la prueba es fácil. Lo difícil es leer bien los resultados: saber qué números importan, qué miden de verdad y dónde buscar datos del mundo real en lugar de puntuaciones simuladas. Este artículo explica cómo hacer una prueba de velocidad, qué significa cada métrica del resultado, por qué las puntuaciones simuladas y las de visitantes reales suelen no coincidir y cómo usar los resultados para mejorar lo que ven las personas que visitan tu web.
Una prueba de velocidad sirve cuando sabes qué hacer con el resultado. Una sola nota sobre 100 dice muy poco. Las métricas individuales que hay detrás, y si vienen de una simulación o de visitantes reales, determinan si el resultado refleja lo que viven tus visitantes. Para entender qué miden esas métricas, lee el artículo sobre qué es el tiempo de carga de una página y cómo se mide.
¿Qué mide realmente una prueba de velocidad web?
Una prueba de velocidad carga una página en un entorno controlado y registra cuánto tardan ciertas partes del proceso de carga. La herramienta mide cosas como la rapidez con la que responde el servidor, cuándo aparece el primer contenido en pantalla, cuándo termina de cargarse el elemento visible más grande, cuánto se desplaza el diseño durante la carga y cuánto tarda la página en responder a los clics. Esas medidas se comparan con umbrales estándar para dar una nota y señalar qué mejorar.
Datos de laboratorio frente a datos de campo
- Datos de laboratorio: los genera una herramienta de pruebas de velocidad. La página se carga desde una ubicación fija, con un dispositivo y una conexión simulados. Los resultados son controlados y repetibles, pero no reflejan todas las condiciones reales de los visitantes
- Datos de campo: se recogen de visitantes reales y se agrupan en una ventana móvil de 28 días. Son los datos que usan los buscadores para puntuar los Core Web Vitals y para el posicionamiento
- Una web puede sacar 90 en una prueba de laboratorio y tener malos datos de campo en Core Web Vitals si los visitantes reales usan dispositivos lentos, conexiones inestables o están lejos del servidor
- Revisa siempre los dos. Los datos de laboratorio sirven para diagnosticar problemas concretos. Los datos de campo son los que determinan el impacto real y en el posicionamiento
¿Cómo se hace bien una prueba de velocidad web?
Prueba primero en móvil
- Los buscadores usan la indexación mobile-first, es decir, _blocked_úan las páginas según su rendimiento en móvil
- Las puntuaciones en móvil casi siempre son más bajas que en escritorio para la misma página, porque los móviles tienen procesadores más lentos y conexiones más variables
- Haz la prueba en móvil y en escritorio, pero considera el resultado en móvil como tu medida principal
Prueba tus páginas más visitadas, no solo la página de inicio
- La página de inicio suele ser la más rápida de una web, porque suele tener menos imágenes y scripts que las páginas interiores
- Las páginas de producto, las entradas del blog y las landing pages suelen puntuar bastante peor y pueden influir más en la experiencia de los visitantes y en el posicionamiento
- Prueba las páginas que reciben más tráfico, no las que mejor van a quedar
Repite cada prueba más de una vez
- Los resultados de laboratorio pueden variar entre ejecuciones por la carga del servidor en ese momento, las condiciones de red del lugar de la prueba y el estado de la caché
- Haz cada prueba dos o tres veces y usa el promedio como punto de partida, en lugar de fiarte de un solo resultado
Prueba antes y después de hacer cambios
- Fija una puntuación de referencia antes de cambiar nada en tu web
- Repite la misma prueba después de cada mejora para medir su efecto concreto
- Con los datos de campo, espera al menos 28 días tras los cambios antes de valorar el impacto, porque es un promedio móvil de 28 días que se actualiza poco a poco
¿Cómo se lee el resultado de una prueba de velocidad?
Empieza por las métricas que fallan, no por la nota general
- Una nota general de 65 no te dice qué arreglar. Las métricas que fallan sí
- Mira qué Core Web Vitals están en el rango de "necesita mejorar" o "malo": LCP, INP y CLS
- Cada métrica que falla apunta a una parte distinta de la página o del proceso de carga que conviene investigar
Qué indica cada métrica que falla
- Time to First Byte (TTFB) alto: la respuesta del servidor es lenta. Revisa la calidad del hosting, la caché del servidor y el rendimiento de la base de datos
- Largest Contentful Paint lento: el elemento principal visible tarda demasiado en cargarse. Suele deberse a imágenes sin optimizar, recursos que bloquean la renderización o una respuesta lenta del servidor
- Total Blocking Time alto o mal Interaction to Next Paint: JavaScript está bloqueando el hilo principal. Los archivos de script grandes y los scripts de terceros son causas habituales
- Cumulative Layout Shift alto: los elementos cambian de posición mientras se carga la página. Lo causan imágenes sin dimensiones definidas, contenido que carga tarde y se inserta encima de otros elementos o banners añadidos de forma dinámica
Cómo leer las recomendaciones
- Las herramientas de velocidad enumeran recomendaciones concretas junto con una estimación del tiempo que ahorra cada arreglo
- Empieza por las recomendaciones con mayor ahorro estimado para lograr el mayor impacto con el menor esfuerzo
- Algunas recomendaciones se refieren a scripts o servicios de terceros que no controlas. Tómalas en cuenta, pero céntrate en lo que sí puedes cambiar
¿Qué puntuaciones son buenas en una prueba de velocidad?
Umbrales de los Core Web Vitals
- Largest Contentful Paint por debajo de 2,5 segundos: bueno
- Interaction to Next Paint por debajo de 200 milisegundos: bueno
- Cumulative Layout Shift por debajo de 0,1: bueno
Rangos de la puntuación general
- De 90 a 100: bueno
- De 50 a 89: necesita mejorar
- De 0 a 49: malo
Cómo usar las referencias en la práctica
- Son referencias absolutas, pero tu puntuación tiene que ser mejor que la de las páginas que compiten contigo por las mismas palabras clave, no solo superar un umbral genérico
- Busca tu palabra clave objetivo y haz pruebas de velocidad en las páginas que aparecen por encima de ti. Si tu LCP es de 3,2 segundos y el suyo de 2,1, esa diferencia te sirve más que una diferencia de nota aislada
Para un desglose detallado de qué miden LCP, INP y CLS y cómo se puntúan, lee el artículo sobre qué son los Core Web Vitals.
¿Cómo seguir la velocidad de tu web con el tiempo?
Fija una referencia antes de empezar a optimizar
- Anota las puntuaciones actuales de las páginas que quieres mejorar antes de hacer cambios
- Apunta qué métricas fallan y por cuánto
- Después de cada ronda de cambios, repite las pruebas y compara con la referencia para medir la mejora real
Revisa los datos de campo con regularidad, no solo tras los cambios
- Los datos de campo de los informes de rendimiento se actualizan en una ventana móvil de 28 días
- Revísalos cada mes, o tras cualquier cambio importante en el contenido, el código o el hosting
- Una caída en los datos de campo suele coincidir con una imagen grande nueva, con un script de terceros recién instalado o con un cambio en la configuración del hosting
Prueba después de publicar contenido nuevo
- Una entrada de blog nueva con imágenes sin optimizar puede ralentizar mucho esa página sin afectar a las demás
- Una landing page nueva con scripts pesados puede introducir bloqueos que una prueba de referencia de la página de inicio nunca revelaría
- Incluir la prueba de velocidad en el proceso de publicación evita que las regresiones se acumulen sin que lo notes
Para una guía completa de las mejoras de mayor impacto según tus resultados, lee el artículo sobre cómo reducir el tiempo de carga de tu web. Si los fallos tienen que ver con las imágenes, lee el artículo sobre cómo optimizar las imágenes para que carguen más rápido.
Cómo ayuda WEMASY con las pruebas de velocidad
El panel de analítica de WEMASY incluye datos de Core Web Vitals de todas las páginas creadas en la plataforma, tomados de datos de campo de visitantes reales. Las puntuaciones de LCP, INP y CLS se ven por página, sin necesidad de hacer pruebas externas. Las páginas que no llegan al umbral bueno aparecen marcadas con la métrica concreta que falla, así que vas directo al problema sin leer un informe completo.
Como la plataforma se encarga automáticamente de la compresión de imágenes, la caché, la minificación y la entrega por CDN, las causas más habituales que señalan las pruebas externas ya están resueltas. Al probar la velocidad de una web creada con WEMASY suelen aparecer problemas del contenido y no de la plataforma, y así es más fácil actuar sobre los resultados.
Mira qué incluye en el creador de webs de WEMASY o consulta los planes en la página de precios.
Preguntas frecuentes
¿Cómo pruebo la velocidad de mi web?
Introduce la URL de tu web en una herramienta de pruebas de velocidad. La herramienta carga tu página en condiciones controladas y da puntuaciones de cada métrica de carga en móvil y en escritorio. Mira las puntuaciones individuales junto con la nota general: las métricas que fallan te dicen dónde centrarte. Para datos de rendimiento reales basados en visitantes, consulta el panel de rendimiento o de analítica de tu web si incluye datos de campo de Core Web Vitals. Con el creador de webs de WEMASY, puedes configurarlo directamente en tu web.
¿Qué es una buena puntuación de velocidad web?
Una nota de 90 o más se considera buena, de 50 a 89 necesita mejorar y por debajo de 50 es mala. Para los Core Web Vitals en concreto, los objetivos son un Largest Contentful Paint por debajo de 2,5 segundos, un Interaction to Next Paint por debajo de 200 milisegundos y un Cumulative Layout Shift por debajo de 0,1. Una página solo supera la evaluación de Core Web Vitals cuando las tres métricas están en el rango bueno según los datos de campo de visitantes reales.
¿Por qué cambia la puntuación de mi prueba de velocidad entre ejecuciones?
Las puntuaciones de laboratorio varían porque las condiciones cambian entre ejecuciones: la carga del servidor en ese momento, las condiciones de red de la ubicación del proveedor de la prueba y el estado de la caché influyen en el resultado. Repetir la prueba varias veces y promediar los resultados da una referencia más fiable. Los datos de campo, tomados de 28 días de mediciones de visitantes reales, son más estables y son mejor indicador del rendimiento constante para el posicionamiento.
¿Por qué mi puntuación en móvil es más baja que en escritorio?
Las pruebas de velocidad en móvil simulan procesadores más lentos y conexiones de red móviles, lo que da puntuaciones más bajas para la misma página que en escritorio. Los buscadores usan la indexación mobile-first, así que lo que cuenta para el posicionamiento es el rendimiento de la página en móvil. Considera la puntuación en móvil como el resultado principal que optimizar, aunque la de escritorio parezca aceptable.
¿Cuál es la diferencia entre datos de laboratorio y datos de campo en una prueba de velocidad?
Los datos de laboratorio vienen de una prueba simulada en condiciones controladas, desde una ubicación y un dispositivo fijos. Son consistentes y útiles para diagnosticar problemas concretos. Los datos de campo vienen de visitantes reales, agrupados en una ventana móvil de 28 días, y reflejan toda la variedad de dispositivos, conexiones y ubicaciones que usan tus visitantes. Los buscadores usan los datos de campo para puntuar los Core Web Vitals. Una web puede puntuar bien en una prueba de laboratorio y tener malos datos de campo si las condiciones reales de los visitantes difieren mucho del entorno de la prueba.
¿Cada cuánto debo hacer una prueba de velocidad?
Haz una prueba de velocidad después de cualquier cambio importante en tu web: añadir imágenes grandes, instalar scripts nuevos, cambiar de hosting o publicar un tipo de página nuevo. Para un seguimiento habitual basta con revisar cada mes los datos de campo de tu analítica o de tu panel de rendimiento. Los datos de campo se actualizan en una ventana móvil de 28 días, así que no hace falta probar a mano con frecuencia, pero las revisiones mensuales ayudan a detectar regresiones antes de que afecten al posicionamiento o a la experiencia de los visitantes.