Es una frustración habitual: el informe de PageSpeed dice 95, los Core Web Vitals están todos en verde, y aun así los visitantes reales siguen describiendo la web como lenta. No es una contradicción, es una diferencia entre dos cosas distintas que se suelen confundir bajo la etiqueta "velocidad".

Datos de laboratorio frente a datos del mundo real

Herramientas como PageSpeed Insights o Lighthouse hacen lo que se llama un test de laboratorio: una visita simulada desde un navegador limpio, en una conexión controlada, sin interferencias de bloqueadores de anuncios, extensiones, o el dispositivo real de un visitante. Los datos del mundo real, a veces llamados field data, vienen de visitantes reales en dispositivos reales con conexiones reales, que varían muchísimo.

Una web puede sacar buena nota en el laboratorio y aun así sentirse lenta en el mundo real porque el test de laboratorio no tiene en cuenta un móvil Android de cinco años con una conexión 4G irregular, algo completamente normal para una parte importante del tráfico de cualquier web.

Las métricas que importan más que la puntuación global

La documentación oficial de Core Web Vitals de Google desglosa la experiencia real en tres métricas que importan más que una única puntuación global:

Una página puede cargar rápido al principio y aun así sentirse rota si los botones tardan un segundo en responder al tocarlos, o si una imagen carga tarde y empuja hacia abajo el texto que estabas a punto de leer. Ninguno de esos dos fallos aparece necesariamente reflejado con claridad en una única puntuación general.

Por qué se suele pasar por alto

La mayoría de las auditorías de velocidad se quedan en la puntuación de laboratorio porque es lo más fácil de medir y de reportar. Los datos del mundo real requieren o bien tráfico suficiente para alimentar el Chrome User Experience Report, o una monitorización dedicada, y su interpretación exige más criterio que leer un único número. Es sinceramente más fácil optimizar para una buena nota de laboratorio que arreglar lo que experimentan los visitantes reales, y esa es exactamente la razón por la que esta diferencia persiste en tantas webs.

Qué es lo que de verdad cierra esa diferencia

Probar con conexiones limitadas y dispositivos antiguos, no solo con el wifi rápido de la oficina en un portátil nuevo. Revisar los datos de campo de Core Web Vitals en Google Search Console, que reflejan visitantes reales y no una simulación. Priorizar la capacidad de respuesta a la interacción (INP) tanto como la velocidad de carga inicial, porque una página que carga rápido pero se siente torpe al interactuar sigue ahuyentando visitantes. Y tratar la estabilidad del layout como un problema real de UX, no como un detalle técnico menor, porque una página que salta es una de las formas más rápidas de que un sitio se sienta poco fiable aunque objetivamente sea rápido.

Una forma rápida de comprobarlo en tu propia web

Abre las herramientas de desarrollador de Chrome, ve a la pestaña Red (Network), y pon el throttling en "Slow 4G" o similar. Recarga la página que te preocupa y obsérvala cargar de verdad, no solo el cronómetro final. Después revisa el informe de Core Web Vitals de Search Console, dentro de la sección de Experiencia, que muestra datos de visitantes reales agrupados por URL. Si los datos de campo son notablemente peores que la puntuación de laboratorio, esa diferencia es exactamente donde debe enfocarse la solución, y suele ser más concreta y más fácil de arreglar de lo que sugiere una queja vaga de "la web se siente lenta". Es exactamente el tipo de comprobación que debería formar parte de cualquier proyecto de diseño web desde el principio, no un añadido de última hora una vez la web ya está publicada.