CrUX: los datos reales de Chrome para medir tu web

Qué es CrUX (Chrome UX Report)

CrUX (Chrome UX Report, o Informe de Experiencia de Usuario de Chrome) es un conjunto de datos público de Google que recoge cómo funcionan realmente los sitios web para usuarios reales de Chrome. Los datos provienen de usuarios que aceptaron compartir estadísticas de uso, y se agregan de forma anónima para reflejar el rendimiento real: cuánto tardó en cargar la página, qué tan rápido respondió a las interacciones y cuánto se movió el diseño (web.dev, sobre CrUX).

La clave es que estos son datos de campo (field data), es decir, medidos en el mundo real, no en un entorno controlado. CrUX captura la variedad de condiciones que Google no podría simular: teléfonos de gama baja, redes 4G saturadas, ubicaciones lejanas del servidor. Por eso Google usa CrUX, y no una prueba de laboratorio, como fuente oficial para evaluar las Core Web Vitals de un sitio.

Una analogía ayuda: los datos de laboratorio son como probar un auto en una pista cerrada en condiciones ideales; CrUX es como ver cómo se comporta ese mismo auto en el tráfico real de una ciudad, con baches y semáforos. Ambas pruebas sirven, pero solo la segunda dice cómo le va a un conductor de verdad, y es la que Google mira para posicionarte.

Datos de campo vs datos de laboratorio

La diferencia entre datos de campo y datos de laboratorio es la distinción más importante para entender CrUX, y confundirlos lleva a "arreglar" números que Google ni siquiera mira. Los datos de campo (CrUX) provienen de usuarios reales y cuentan para el ranking; los de laboratorio (Lighthouse) provienen de una prueba simulada y sirven para diagnosticar. Esta tabla los enfrenta:

El punto que más desconcierta se resuelve con esta tabla: si tu web saca 98 en Lighthouse pero CrUX la marca en "necesita mejora", no hay contradicción. Lighthouse midió una carga ideal; CrUX midió a tus usuarios reales, que navegan peor. Ambos números son ciertos, pero solo uno posiciona. Para diagnosticar por qué algo va lento, usa el laboratorio; para saber cómo te evalúa Google, mira CrUX.

Hay una capacidad exclusiva de CrUX que conviene destacar: solo el campo puede medir el INP. Como el INP (Interaction to Next Paint) mide la respuesta a clics y toques reales, una prueba de laboratorio sin usuario no puede calcularlo. Esto por sí solo hace que los datos de campo sean imprescindibles.

La ventana de 28 días y cada cuánto se actualiza

CrUX se basa en una ventana móvil de 28 días y se actualiza a diario, incorporando el día más reciente y descartando el más antiguo. El valor que ves en cualquier momento resume, por tanto, las visitas de los 28 días anteriores: no es una foto instantánea, sino un promedio deslizante de casi un mes. La API de CrUX va aproximadamente dos días por detrás de la fecha actual, porque espera a tener los datos completos de cada jornada antes de publicarlos.

Esto tiene una consecuencia práctica que frustra a quien no la conoce: un arreglo tarda en verse. Si hoy mejoras tu rendimiento, las visitas lentas de días anteriores siguen en el promedio hasta que salen de la ventana, así que pueden pasar de dos a cuatro semanas hasta que la mejora se refleje del todo. Por eso, para verificar un cambio al instante se usa Lighthouse, y para confirmar el impacto real se espera a que la ventana se renueve.

También explica por qué algunos sitios no tienen datos de CrUX. Google solo publica datos de una página u origen cuando recibe suficiente tráfico de Chrome para que la muestra sea representativa y mantenga el anonimato. Un sitio nuevo o de bajo tráfico puede quedar por debajo de ese umbral y aparecer sin datos de campo; en ese caso solo tendrás laboratorio hasta que las visitas crezcan.

Cómo se usa CrUX en Search Console y PageSpeed

CrUX no es una herramienta que abras directamente: es la fuente de datos que alimenta a otras herramientas de Google que sí usas a diario. Las dos principales son PageSpeed Insights y el informe de Core Web Vitals de Search Console, y ambas muestran los mismos datos de campo de CrUX presentados de forma distinta.

• PageSpeed Insights (pagespeed.web.dev): pega una URL y su sección superior muestra los datos de campo de CrUX de esa página y de su origen, mientras que la sección inferior ejecuta una prueba fresca de Lighthouse. Es la forma más rápida de ver campo y laboratorio de una página concreta, uno al lado del otro, y de detectar cuándo discrepan.
• Google Search Console: su informe de Core Web Vitals se alimenta de CrUX y agrupa todas las URLs del sitio por estado —buena, necesita mejora o pobre—, juntando páginas similares para dar un panorama del sitio completo. Es la mejor vista de conjunto: avisa cuándo un grupo entero de páginas cae en rojo y en qué métrica.

Para quien quiera ir más allá, CrUX también está disponible de forma técnica: hay una API pública (gratuita, con un límite de 150 consultas por minuto) para consultar los datos de una URL u origen mediante programación, y el conjunto completo a nivel de origen está en BigQuery para análisis a gran escala. La mayoría de los sitios no necesita esto, pero está ahí para quien haga seguimiento masivo o comparativas de sector.

Qué hacer con lo que dice CrUX

CrUX te dice el "qué" (esta página está en rojo en LCP), pero no el "por qué", y ese es el trabajo que sigue. El flujo correcto es empezar en Search Console para ver qué grupos de páginas fallan y en qué métrica, pasar a PageSpeed Insights para confirmar en la página concreta, y usar el diagnóstico de Lighthouse para descubrir la causa técnica. Solo entonces se optimiza.

Aquí entra un factor que CrUX refleja pero que muchos ignoran: como los datos de campo incluyen a tus usuarios peor servidos, mejorar el TTFB del servidor ayuda a todos a la vez. Un hosting con discos NVMe, caché a nivel de servidor como LiteSpeed y baja latencia baja el suelo de carga para cada visita, incluidas las lentas que arrastran tu percentil hacia abajo en CrUX. Para traducir lo que CrUX te muestra en acciones concretas por métrica, la guía completa de Core Web Vitals recorre qué hacer con el LCP, el INP y el CLS, y cuándo el problema es el servidor y cuándo es el código.