Datos de campo y Chrome UX Report (CrUX)

Cuando se habla de rendimiento web conviven dos formas de medir. Una se hace en un entorno controlado, con un dispositivo fijo, una red simulada y una única carga de la página; es lo que produce una auditoría de laboratorio. La otra registra lo que ocurre en los navegadores de las personas que entran de verdad al sitio, con su móvil, su conexión y su caché.

El Chrome UX Report, conocido por la sigla CrUX, es el conjunto de datos público donde Google publica esa segunda medición. No recoge la experiencia de cualquiera: solo entran usuarios de Chrome que tienen activado el envío de estadísticas de uso, sincronizan el historial del navegador y no han configurado una frase de contraseña de sincronización. Quedan fuera Chrome en iOS, las vistas web integradas en aplicaciones Android y el resto de navegadores basados en Chromium, además de Safari y Firefox.

La página también tiene que cumplir condiciones. Debe ser públicamente descubrible, con los mismos criterios de indexabilidad que aplica un buscador, y debe recibir un mínimo de visitantes para que la distribución sea estadísticamente sólida. Google no publica ese umbral.

El valor que ves no procede de una carga concreta sino de una ventana móvil de 28 días. Cada actualización recalcula el conjunto con los datos de los 28 días anteriores, así que una mejora publicada hoy tarda semanas en reflejarse por completo.

Dentro de esa ventana no hay un número único, hay una distribución de experiencias. Para resumirla se toma el percentil 75 de las visitas: el valor que el 75 % de las cargas iguala o mejora. El criterio ignora la cuarta parte de visitas con peor experiencia, de modo que una página puede aprobar mientras una minoría apreciable sigue sufriendo esperas. La medición se separa además entre móvil y escritorio, y cada segmento se evalúa por su cuenta.

Hay varias puertas de entrada a los mismos datos. El informe de Core Web Vitals de Search Console se actualiza a diario, guarda tres meses de histórico y agrupa URLs parecidas cuando una sola no reúne suficientes muestras. Las herramientas públicas de análisis de velocidad muestran el promedio de 28 días de la URL consultada y de su dominio, sin histórico. La API devuelve datos diarios a nivel de página y de dominio; la API de histórico entrega 40 periodos semanales. El conjunto alojado en BigQuery es mensual, se publica el segundo martes posterior al periodo recogido, cubre desde 2017 y solo ofrece el nivel de dominio.

La pregunta que llega a cualquier equipo de SEO es siempre la misma: ¿por qué la auditoría de laboratorio sale en verde y el informe de Search Console sigue en rojo? Porque miden cosas distintas. El laboratorio ejecuta una carga desde una máquina, con una red simulada y la caché vacía, y no puede saber cuándo va a pulsar el usuario. Para la métrica de interactividad, de hecho, la herramienta de laboratorio informa de un sustituto en lugar de la métrica real.

El campo recoge lo que el laboratorio no ve: móviles de gama media, redes móviles reales, visitas repetidas con caché caliente, restauraciones desde el historial que aparecen al instante, banners de consentimiento, anuncios y contenido personalizado. Una puntuación alta de laboratorio indica que la página tiene margen técnico, no que tus visitantes la vivan así.

Para la búsqueda cuenta el campo. El informe con el que Google clasifica cada URL como buena o deficiente se alimenta de las mediciones de usuarios reales, y la auditoría de laboratorio funciona como diagnóstico: enumera causas probables y buenas prácticas a partir de una carga predefinida. Sirve para saber dónde tocar, no para dar el problema por resuelto.

• Toma la decisión con el informe de campo y usa la auditoría de laboratorio solo para localizar la causa técnica.
• Añade medición propia en el sitio si tu tráfico no llega al umbral del conjunto público o si necesitas segmentar por plantilla, país o dispositivo.
• Consulta el nivel de página cuando exista y baja al nivel de dominio solo si esa URL no reúne muestras suficientes.
• Cuenta con la ventana de 28 días al planificar y deja pasar al menos un mes completo antes de juzgar un despliegue.
• Revisa móvil y escritorio por separado, porque el resultado agregado esconde el segmento que falla.
• Consulta los umbrales concretos de cada métrica en su entrada correspondiente antes de fijar un objetivo interno.

• Dar una página por buena porque la auditoría de laboratorio marca 100 y no volver a mirar el informe de campo.
• Interpretar la ausencia de datos como un problema de rendimiento cuando suele significar que la URL no reúne visitantes suficientes o no es indexable.
• Concluir que el conjunto público está equivocado porque una prueba puntual da otro número, cuando la diferencia viene de la ventana de 28 días.
• Optimizar la puntuación global de la herramienta de laboratorio en lugar de las métricas que se evalúan en campo.
• Dejar en noindex o devolviendo un código distinto de 200 páginas que sí quieres medir, lo que las excluye por el criterio de descubrimiento.