Informe de experiencia de usuario de Chrome (CrUX)

TL;DR — CrUX es la recopilación de datos de velocidad del mundo real de usuarios reales de Chrome. Son los datos que Google usa para evaluar sus Core Web Vitals, no la puntuación de laboratorio que una herramienta como Lighthouse genera en una sola prueba. Por eso su puntuación de Lighthouse puede aparecer en verde mientras Search Console dice que necesita mejoras: miden cosas distintas.

Qué es CrUX

El Chrome User Experience Report —CrUX, en abreviatura— es un conjunto de datos gratuito que Google publica y que muestra cómo viven las personas reales, con dispositivos y redes reales, la experiencia de los sitios web. En lugar de probar una página una vez en un laboratorio, CrUX recopila mediciones de un gran número de usuarios reales de Chrome y presenta el resultado.

Esto se llama datos de campo (a veces, datos de «usuarios reales»). Es lo contrario de los datos de laboratorio, que es lo que produce una herramienta como Lighthouse al cargar su página una vez en una máquina de prueba controlada. Ambos son útiles, pero solo uno es el que Google consulta para evaluar su sitio.

Por qué importa

CrUX es el conjunto de datos oficial del programa Core Web Vitals. Los sistemas de posicionamiento de Google usan los Core Web Vitals medidos a partir de datos de campo de usuarios reales, no una puntuación de laboratorio de Lighthouse. Así que, si solo mira su número de Lighthouse, puede estar mirando algo completamente distinto de lo que importa.

Ya ha visto CrUX aunque no lo supiera. La sección «Descubra lo que experimentan sus usuarios reales» de PageSpeed Insights es CrUX. El informe de Core Web Vitals de Search Console es CrUX. Esos son los números que cuentan.

Lo que la mayoría entiende mal

Una buena puntuación de Lighthouse no significa que sus Core Web Vitals sean buenos. Lighthouse se ejecuta una vez, en un dispositivo simulado, con una red limitada artificialmente y una caché vacía. Sus visitantes reales usan una mezcla de teléfonos, portátiles, conexiones rápidas y lentas, y ubicaciones cercanas y lejanas. CrUX captura ese desorden; Lighthouse no. Una página puede obtener un 95 en Lighthouse y aun así mostrar «Poor» en CrUX si la mayoría de sus usuarios reales utiliza móviles lentos.

Hay otra cosa que sorprende a mucha gente: no todas las páginas están en CrUX. Una URL necesita suficientes visitas reales para incluirse. Muchas páginas con poco tráfico no tienen datos de CrUX, así que las herramientas recurren a mostrar los datos de todo el sitio (el «origen») o simplemente dicen que todavía no hay datos de campo.

¿Quiere conocer la metodología —la ventana de 28 días, el percentil 75, los datos de origen frente a los de URL y todas las formas de obtener datos de CrUX—? Cambie a la pestaña Avanzado.

TL;DR — CrUX es el Chrome User Experience Report oficial: datos de UX de campo del mundo real, agregados a partir de usuarios de Chrome aptos —los que cumplen los criterios de activación voluntaria, sincronización y plataforma compatible— y el conjunto de datos que sustenta el programa Core Web Vitals. Se informa en el percentil 75 sobre una ventana de agregación de 28 días, tanto a nivel de origen como de URL. La cobertura es parcial: nunca incluye a todos los usuarios de Chrome ni a todos los visitantes, sino solo a usuarios aptos de Chrome en plataformas compatibles (sin Chrome en iOS ni Edge/Safari/Firefox), y una página necesita suficientes muestras para incluirse. Por eso muchas URL con poco tráfico no tienen datos de CrUX y las herramientas recurren al nivel de origen o a «sin datos». Actualmente lo exponen seis superficies: PageSpeed Insights, Search Console, la API de CrUX (diaria), la API de History (semanal), BigQuery (mensual) y CrUX Vis. Compruebe la documentación actual, porque la cadencia y las cuotas pueden cambiar. CrUX es campo; Lighthouse es laboratorio: por eso discrepan.

CrUX es la capa de datos de campo de Core Web Vitals

Google lo describe claramente: “The Chrome User Experience Report … is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (traducción) «El Chrome User Experience Report … es un conjunto de datos que refleja cómo viven los usuarios reales de Chrome la experiencia de destinos populares de la web». Y no es un proyecto secundario: “CrUX is the Google dataset of the Web Vitals program. All user-centric Core Web Vitals metrics are represented.” (traducción) «CrUX constituye el conjunto de datos de Google para el programa Web Vitals. Están representadas todas las métricas de Core Web Vitals centradas en el usuario». Los datos se “used by Google Search to inform the page experience ranking factor.” (traducción) «utilizan en Google Search para informar el factor de posicionamiento de experiencia de página».

El modelo mental es el siguiente: Core Web Vitals son las métricas; CrUX es el conjunto de datos donde viven. Cuando Search evalúa sus CWV, lee CrUX. Ese único hecho resuelve la mayor parte de la confusión de esta página.

Cómo recopila datos CrUX

CrUX se construye a partir de usuarios reales de Chrome, pero de un subconjunto concreto y apto, no de todos los usuarios de Chrome ni de todos los visitantes de su sitio. Las experiencias de un usuario solo se agregan si cumple los cuatro criterios: “Enable usage statistic reporting. Sync their browser history. Not have a Sync passphrase set. Use a supported platform.” (traducción) «Activar los informes de estadísticas de uso. Sincronizar el historial del navegador. No tener configurada una frase de contraseña de sincronización. Usar una plataforma compatible».

«Plataforma compatible» hace mucho trabajo. Se incluyen Chrome de escritorio en Windows, macOS, ChromeOS y Linux, además de Chrome para Android (incluidos Custom Tabs y WebAPKs). Se excluyen: Chrome en iOS, Android WebViews y “other Chromium browsers.” (traducción) «otros navegadores Chromium». En la práctica, Microsoft Edge, Samsung Internet, Safari y Firefox no están en CrUX, y tampoco ningún navegador de iOS, porque todos funcionan con WebKit.

Este es el punto ciego que conviene interiorizar. Si gestiona un sitio de comercio electrónico o de medios donde la mayor parte del tráfico procede de iPhone/Safari, CrUX puede estar midiendo una minoría de su audiencia real. Los datos no son erróneos; simplemente no representan a todo el mundo.

Por qué algunas páginas no tienen datos de CrUX

CrUX no cubre todas las páginas, y esto confunde a mucha gente. Según Google: “Not all origins or pages are represented in the dataset. There are separate eligibility criteria for origins and pages, primarily that they must be publicly discoverable and there must be a large enough number of visitors in order to create a statistically significant dataset.” (traducción) «No todos los orígenes o páginas están representados en el conjunto de datos. Existen criterios de elegibilidad distintos para los orígenes y las páginas; principalmente, deben poder descubrirse públicamente y debe haber un número suficientemente grande de visitantes para crear un conjunto de datos estadísticamente significativo». El umbral exacto de popularidad se mantiene deliberadamente oculto: trate cualquier número concreto de visitantes que vea citado como una estimación no oficial, no como una regla documentada.

La elegibilidad de la página y del origen se evalúa por separado. Un origen puede tener suficiente tráfico apto para aparecer en los informes aunque muchas de sus páginas individuales no lo tengan; por eso un dominio puede mostrar datos a nivel de origen mientras una URL concreta no muestra ninguno. Y un resultado ausente no es una puntuación: solo significa que Google no dispone de una muestra apta suficientemente grande para informar sobre ese alcance. «Sin datos» no significa cero, aprobado ni suspenso.

También hay requisitos mecánicos: la página debe devolver 200 (después de las redirecciones) y no debe tener noindex (en la cabecera o en una etiqueta meta). Y existe una regla del 20 %: “origins or pages having more than 20% of their total traffic excluded due to ineligible combinations of dimensions are excluded entirely from the dataset.” (traducción) «los orígenes o páginas cuyo tráfico total excluido por combinaciones no aptas de dimensiones supere el 20 % quedan excluidos por completo del conjunto de datos».

He medido hasta qué punto se reduce esta cobertura. En mi estudio de datos de Core Web Vitals combiné CrUX con un rastreo de Ahrefs de 43,66 millones de páginas. Solo 5,21 millones —aproximadamente el 11,9 %— tenían al menos una métrica de Core Web Vitals en el conjunto de datos de CrUX de enero de 2022. El resto tenía demasiado poco tráfico para cumplir los requisitos. Ese es el estado normal de la web, no un error.

Cuando una URL concreta no tiene datos, las herramientas hacen una cascada. En PageSpeed Insights: CrUX a nivel de URL → si es insuficiente, se recurre a CrUX a nivel de origen → si también falta, no hay datos de campo y solo queda la sección de laboratorio de Lighthouse. La nota de Google sobre por qué las consultas detalladas fallan más a menudo dice: “The more fine-grained the request is, for example a specific combination of URL and form factor, the fewer user experiences it will include. This may lead to more frequent ‘not found’ errors.” (traducción) «Cuanto más detallada sea la solicitud, por ejemplo una combinación concreta de URL y factor de forma, menos experiencias de usuario incluirá. Esto puede provocar errores de “no encontrado” con más frecuencia».

Cómo agrega CrUX: 28 días y p75

Dos números definen cómo informa CrUX de todo:

La ventana móvil de 28 días. “The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.” (traducción) «Los datos del Chrome UX Report son un promedio móvil de 28 días de métricas agregadas». Cada lectura que ve es un agregado de los 28 días anteriores. Una consecuencia que Google señala: “the collectionPeriod will always show 28-days, even if the data is not for the full 28 days (for example if a page was launched less than 28 days ago).” (traducción) «collectionPeriod siempre mostrará 28 días, aunque los datos no correspondan a los 28 días completos (por ejemplo, si una página se lanzó hace menos de 28 días)».

La consecuencia práctica —y llevo años señalándola— es que las correcciones tardan en aparecer. CrUX lleva aproximadamente dos días de retraso respecto al tiempo real y cada lectura es una agregación de la ventana anterior, no un número en directo; por eso un cambio no sustituye por completo los datos antiguos hasta que se acumulan suficientes sesiones nuevas aptas y las antiguas salen de la ventana. Un mes aproximadamente es una regla práctica razonable, pero no una cuenta atrás fija: la rapidez con que aparece una corrección depende del tráfico apto que reciba la página o el origen, de la vida útil de la métrica y del periodo de recopilación indicado en ese registro. Como digo en mi guía de CLS, “it takes a while to see the impact of changes.” (traducción) «tarda un tiempo en verse el impacto de los cambios». Esto sirve para ajustar las expectativas: no prometa movimiento desde el primer día ni una fecha exacta.

El percentil 75 (p75). Los CWV se evalúan en p75, no en la mediana. La definición de Google es: “75% of page loads experienced the given metric at or less than this value.” (traducción) «El 75 % de las cargas de página experimentó la métrica indicada en este valor o por debajo». Por tanto, para aprobar, tres de cada cuatro cargas deben estar en el umbral «bueno» o por debajo. Una salvedad importante de Google: los valores de percentil “are synthetically derived, it does not imply that any user actually experienced the value indicated.” (traducción) «se derivan sintéticamente; no implica que ningún usuario haya experimentado realmente el valor indicado». Un p75 «bueno» no significa literalmente que «el 75 % de los usuarios esté satisfecho»: significa que el 75 % de las cargas de página llegó al umbral o por debajo, y el cuartil superior no se penaliza mientras eso se mantenga.

Nivel de origen frente a nivel de URL

CrUX informa con dos niveles de granularidad, y la diferencia es una de las cosas más importantes que debe entender un profesional de SEO.

• Nivel de origen agrega “all data present for all pages in that origin … together” (traducción) «todos los datos disponibles de todas las páginas de ese origen … conjuntamente»: en esencia, el promedio de todo el dominio.
• Nivel de URL devuelve “only data for that specific URL.” (traducción) «solo los datos de esa URL concreta».

Estos niveles pueden divergir mucho. Un sitio puede mostrar un CrUX de nivel de origen «Good» mientras una página de destino concreta y valiosa muestra «Poor», porque las páginas más rápidas de otras partes compensan su promedio de origen. Como PSI recurre a los datos de origen cuando una URL no tiene suficientes datos propios, puede estar mirando el promedio de su dominio y pensando que mira la página que tiene delante.

Mi estudio de datos mostró esta diferencia a gran escala: en esa muestra de enero de 2022, aproximadamente el 33 % de los sitios aprobó los CWV a nivel de origen, pero solo aproximadamente el 21,2 % de las páginas individuales aprobó. Las cifras de nivel de dominio eran mayores en parte porque incorporaban visitas repetidas y almacenadas en caché de todo el sitio. Trate esas cifras concretas como una instantánea fechada de una muestra grande, no como una tasa universal actual; pero la lección subyacente sigue vigente: compruebe los datos a nivel de URL de sus páginas clave siempre que estén disponibles y no suponga que un origen aprobado implica que todas sus páginas lo estén.

CrUX también separa por factor de forma —PHONE, TABLET y DESKTOP— y Google evalúa usando datos adecuados al factor de forma. Por eso sus cifras móviles y de escritorio difieren.

Campo frente a laboratorio: por qué su puntuación de Lighthouse no coincide

Esta es la tensión central y conviene ser preciso. Los datos de campo se “determined by monitoring all users who visit a page and measuring … each one of those users’ individual experiences” (traducción) «determinan mediante la supervisión de todos los usuarios que visitan una página y la medición de … las experiencias individuales de cada uno»; esa categoría general también se llama RUM (monitorización de usuarios reales), y CrUX es una implementación pública concreta de ella. Los datos de laboratorio se “determined by loading a web page in a controlled environment with a predefined set of network and device conditions.” (traducción) «determinan al cargar una página web en un entorno controlado con un conjunto predefinido de condiciones de red y dispositivo».

Difieren porque los datos de campo “includes a wide variety of network and device conditions as well as a myriad of different types of user behavior,” (traducción) «incluyen una amplia variedad de condiciones de red y dispositivo, además de una multitud de tipos de comportamiento de usuario», mientras que una prueba de laboratorio “intentionally limits the number of variables” (traducción) «limita intencionadamente el número de variables»: un dispositivo, una red, una ubicación y normalmente una caché fría. PageSpeed Insights muestra literalmente ambos: arriba, la sección de campo de CrUX (con la que Google le evalúa), y abajo, la sección de laboratorio de Lighthouse (una aproximación para depurar). Como dicen los documentos de CrUX: “CrUX is a collection of real-user experiences from the field, while Lighthouse is a controlled test in the lab.” (traducción) «CrUX es un conjunto de experiencias de usuarios reales en campo, mientras que Lighthouse es una prueba controlada en el laboratorio».

Así que, cuando su ejecución local de Lighthouse dice 95 pero Search Console dice «Needs Improvement», no hay nada roto: está comparando una carga de laboratorio única y limpia con la realidad desordenada de sus usuarios reales.

CrUX no es lo mismo que su RUM propio. Una herramienta RUM privada y de primera parte (instrumentada con algo como la biblioteca JS web-vitals) y CrUX pueden informar de cifras distintas para la misma página, porque sus poblaciones, estados de consentimiento, muestreos y vidas útiles de las métricas no son idénticos. Piense en las tres opciones como trabajos distintos:

• CrUX — el punto de referencia público y gratuito de las experiencias aptas de Chrome. Úselo para ver lo que ve Google y comprobar el rendimiento de campo de un competidor.
• RUM privado — su propia monitorización instrumentada. Úselo cuando necesite todos los navegadores (no solo Chrome apto), detalles por usuario o segmento, o alertas en tiempo real que la ventana móvil de CrUX no puede ofrecer.
• Monitorización sintética (Lighthouse, WebPageTest y similares) — una prueba controlada y repetible. Úsela para comprobar regresiones antes de publicar y diagnosticar por qué una métrica de campo es mala, no para declarar corregida la métrica de campo.

Para conocer la teoría general de campo frente a laboratorio más allá de CrUX —opciones de herramientas RUM, configuraciones de monitorización sintética y el marco de decisión más amplio— consulte el análisis detallado Datos de campo frente a datos de laboratorio.

Qué contiene CrUX (y qué no)

Las tres Core Web Vitals están presentes: Largest Contentful Paint (carga), Interaction to Next Paint (capacidad de respuesta) y Cumulative Layout Shift (estabilidad visual), evaluadas en p75 frente a estos umbrales:

Además de las tres principales, CrUX también incluye métricas de apoyo como FCP (First Contentful Paint), TTFB experimental y RTT (Round Trip Time, que sustituyó a la dimensión ECT retirada en enero de 2025), además de subpartes de la imagen de LCP y tipos de navegación.

Lo que no tiene CrUX son diagnósticos exclusivos de laboratorio: Total Blocking Time, Speed Index y Time to Interactive no existen en CrUX; solo se obtienen de Lighthouse. Y tenga en cuenta el cambio histórico: INP sustituyó a FID como Core Web Vital en marzo de 2024, y FID se eliminó de CrUX en agosto de 2024 (y de BigQuery en septiembre de 2024). Muchas guías antiguas siguen mencionando FID: están desactualizadas.

Seis formas de acceder a CrUX

La cadencia, las cuotas y la profundidad histórica que aparecen abajo están actualizadas a la fecha de este texto. Google ya las ha cambiado antes (la retirada del CrUX Dashboard es un ejemplo reciente), así que considérelo una instantánea y consulte los documentos oficiales enlazados para conocer las cifras actuales antes de crear algo que dependa de ellas.

Algunos detalles que conviene conocer:

• PageSpeed Insights es la vista por URL más rápida. Datos de campo arriba, laboratorio abajo; es gratuito y no necesita clave de API.
• El informe de Core Web Vitals de Search Console agrupa sus URL indexadas por estado (Good / Needs Improvement / Poor), con vistas separadas para móvil y escritorio. Como agrupa las páginas por patrón, un «grupo de páginas» puede mezclar URL rápidas y lentas; por eso una página puede verse bien en PSI pero aparecer señalada en GSC.
• La API de CrUX (POST …/v1/records:queryRecord) devuelve la ventana actual de 28 días con p75 y clases del histograma; consulte por origin o por url (son mutuamente excluyentes). Es gratuita, necesita una clave de API de Google y está “limited to 150 queries per minute per Google Cloud project.” (traducción) «limitada a 150 consultas por minuto por proyecto de Google Cloud».
• La API de History de CrUX ofrece hasta 40 semanas de instantáneas semanales: datos de tendencias sin tocar BigQuery.
• BigQuery es la opción para trabajar a escala (historial desde 2017 y datos por país que las API no exponen), pero es solo de nivel de origen: las tablas estándar no contienen datos por URL.
• CrUX Vis (cruxvis.withgoogle.com) es la herramienta visual. Nota: el antiguo CrUX Dashboard en Looker Studio quedó obsoleto en noviembre de 2025 y su conector dejó de actualizarse. Si una guía todavía le dirige al Dashboard, está desactualizada; use CrUX Vis.

¿CrUX mejora el posicionamiento?

CrUX es la fuente de datos de campo de la señal de experiencia de página, así que sí, alimenta una entrada de posicionamiento; pero moderaría las expectativas sobre cuánto vale. Mi opinión habitual, de mi guía de Core Web Vitals, es: “I don’t expect much, if any, improvement in rankings from improving Core Web Vitals,” (traducción) «no espero mucha mejora, si es que espero alguna, en el posicionamiento por mejorar los Core Web Vitals», y “unless you are extremely slow, I generally won’t prioritize fixing them.” (traducción) «salvo que sea extremadamente lento, por lo general no daré prioridad a corregirlos». El argumento más sólido para preocuparse por sus cifras de CrUX es la experiencia de usuario, no una subida de posiciones. Entienda los datos y no entre en pánico.

Dónde encaja esto

CrUX es el motor de datos de campo bajo el hub de Core Web Vitals. Cada métrica que informa tiene su propio análisis detallado —Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift—, y las dos herramientas principales que muestran CrUX son PageSpeed Insights (campo + laboratorio) y Google Lighthouse (solo laboratorio). Si solo recuerda una cosa: la separación entre campo y laboratorio explica por qué una puntuación de laboratorio en verde y una evaluación de CWV fallida pueden ser ciertas al mismo tiempo.

Resumen de IA

Una síntesis de la versión avanzada:

• CrUX = datos de campo y es el conjunto de datos detrás de Core Web Vitals. Cuando Google evalúa sus CWV para Search, lee CrUX, no una puntuación de laboratorio de Lighthouse.
• La recopilación se limita a experiencias aptas de Chrome: usuarios que cumplen cuatro criterios documentados (activación voluntaria, historial sincronizado, sin frase de contraseña de Sync y plataforma compatible), nunca todos los usuarios de Chrome ni todos los visitantes. Sin Chrome en iOS, sin Android WebViews ni Edge/Safari/Firefox. En audiencias dominadas por Safari, CrUX mide una minoría de usuarios reales.
• La cobertura es parcial y la elegibilidad de página y origen se evalúa por separado: un origen puede cumplir los requisitos aunque muchas de sus páginas no lo hagan. Un resultado ausente significa «no hay una muestra apta suficiente para informar», no cero ni aprobado. En mi muestra de enero de 2022 de 43,66 millones de páginas únicas de Site Audit, solo aproximadamente el 11,9 % tenía al menos una métrica de Core Web Vitals en CrUX. Las herramientas hacen una cascada: URL → origen → «sin datos» (solo laboratorio).
• La agregación es una ventana móvil de 28 días en p75, no un promedio literal ni un número en directo. p75 significa que el 75 % de las cargas estuvo en ese valor o por debajo; los valores se derivan sintéticamente. Las correcciones suelen tardar aproximadamente un mes en registrarse, pero no hay una garantía fija de 30 días: depende del volumen de tráfico apto, la vida útil de la métrica y el retraso propio de la ventana.
• El origen frente a la URL importa. Origen = agregado de todo el dominio; URL = esa página. Difieren: mi estudio encontró que aproximadamente el 33 % de los sitios aprobó a nivel de origen, pero solo aproximadamente el 21,2 % de las páginas individuales. Compruebe el nivel de URL para las páginas clave.
• Campo frente a laboratorio explica por qué Lighthouse (una carga de laboratorio limpia) discrepa de CrUX (usuarios reales y desordenados). PSI muestra ambos. CrUX es una forma pública concreta de RUM; una herramienta RUM privada y de primera parte y CrUX aún pueden discrepar.
• Seis superficies de acceso (cadencias y cuotas vigentes a la fecha de este texto; verifíquelas antes de basarse en ellas): PSI (diaria, por URL), Search Console (semanal), API de CrUX (diaria), API de History (semanal, 40 semanas), BigQuery (mensual, solo origen, hasta 2017) y CrUX Vis (visual semanal). El CrUX Dashboard quedó obsoleto en noviembre de 2025: use CrUX Vis.
• El impacto en el posicionamiento es pequeño; el motivo real para preocuparse por CrUX es la experiencia de usuario.

Documentación oficial

Documentación primaria de CrUX del equipo de Chrome en developer.chrome.com.

• Descripción general de CrUX: qué es CrUX, su función en el programa Web Vitals y cómo lo usa Search.
• Metodología de CrUX: los cuatro criterios de elegibilidad de usuarios, las plataformas incluidas/excluidas, la regla del 20 %, la eliminación de URL y el tratamiento de SPA/iframe.
• API de CrUX: la ventana de 28 días, la definición de p75, el endpoint queryRecord, el límite de 150 solicitudes por minuto y la cadencia diaria.
• API de History de CrUX: instantáneas semanales y hasta 40 semanas de historial.
• CrUX en BigQuery: publicación mensual (segundo martes), solo a nivel de origen, historial desde 2017 y datos por país.
• CrUX Vis: la herramienta visual que sustituyó al CrUX Dashboard obsoleto.
• Guía de PageSpeed Insights + CrUX: la cascada de reserva URL → origen → sin datos y el marco campo frente a laboratorio.
• Notas de la versión de CrUX: la transición FID→INP, la retirada de FID y la cronología de obsolescencia del Dashboard.

Contexto relacionado (web.dev)

• Diferencias entre datos de laboratorio y de campo: por qué una puntuación de laboratorio y CrUX discrepan.
• Diferencias entre CrUX y RUM: detalles de Chrome-only / iOS excluido / SPA / iframe.

Citas de las fuentes

Declaraciones registradas de la documentación de CrUX del equipo de Chrome. Cada enlace profundo salta al pasaje citado.

Qué es CrUX

• “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (traducción) «El Chrome User Experience Report (también conocido como Chrome UX Report o CrUX, en abreviatura) es un conjunto de datos que refleja cómo viven los usuarios reales de Chrome la experiencia de destinos populares de la web». [Ir a la cita](https://developer.chrome.com/docs/crux#:~:text=The%20Chrome%20User%20Experience%20Report%20(also%20known%20as%20the%20Chrome%20UX%20Report)
• “CrUX is the Google dataset of the Web Vitals program. All user-centric Core Web Vitals metrics are represented.” (traducción) «CrUX es el conjunto de datos de Google del programa Web Vitals. Incluye todas las métricas de Core Web Vitals centradas en el usuario». Ir a la cita

Elegibilidad y cobertura

• “Not all origins or pages are represented in the dataset. There are separate eligibility criteria for origins and pages, primarily that they must be publicly discoverable and there must be a large enough number of visitors in order to create a statistically significant dataset.” (traducción) «El conjunto de datos no incluye todos los orígenes ni todas las páginas. La elegibilidad de orígenes y páginas se decide por separado; deben poder descubrirse públicamente y reunir suficientes visitantes para generar datos estadísticamente significativos». Ir a la cita
• Los cuatro criterios de usuario: “Enable usage statistic reporting. Sync their browser history. Not have a Sync passphrase set. Use a supported platform.” (traducción) «Habilitar los informes de uso. Sincronizar el historial del navegador. No configurar una frase de contraseña de sincronización. Utilizar una plataforma compatible». Ir a la cita

Agregación

• “The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.” (traducción) «Los datos del Chrome UX Report son un promedio móvil de 28 días de métricas agregadas». Ir a la cita
• “75% of page loads experienced the given metric at or less than this value.” (traducción) «El 75 % de las cargas de página experimentó la métrica indicada en este valor o por debajo». Ir a la cita
• “The values for each percentile are synthetically derived, it does not imply that any user actually experienced the value indicated, only that some percentage of page loads experienced a metric value that was less than the value given.” (traducción) «Los valores de cada percentil se derivan sintéticamente; no implica que ningún usuario haya experimentado realmente el valor indicado, solo que un porcentaje de las cargas de página experimentó un valor de métrica inferior al valor dado». Ir a la cita

Origen frente a URL

• “When the identifier is an origin all data present for all pages in that origin are aggregated together.” (traducción) «Cuando el identificador es un origen, todos los datos disponibles de todas las páginas de ese origen se agregan conjuntamente». / “When the identifier is a URL, only data for that specific URL will be returned.” (traducción) «Cuando el identificador es una URL, solo se devolverán los datos de esa URL concreta». Ir a la cita

Campo frente a laboratorio (web.dev)

• “Field data is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” (traducción) «Los datos de campo se determinan supervisando a todos los usuarios que visitan una página y midiendo un conjunto determinado de métricas de rendimiento para la experiencia individual de cada uno». Ir a la cita
• “The Chrome User Experience Report, as its name suggests, is Chrome-only.” (traducción) «El Chrome User Experience Report, como su nombre sugiere, es exclusivo de Chrome». Ir a la cita

Superficies de acceso a CrUX — guía rápida

Dónde obtener datos de CrUX y para qué sirve cada superficie — la cadencia y las cuotas son las vigentes a la fecha de este texto; consulte la documentación oficial antes de basarse en ellas.

Datos rápidos

• Ventana: los 28 días anteriores, siempre, incluso en páginas recién lanzadas.
• Evaluación: p75 (el 75 % de las cargas en el valor o por debajo), no un promedio.
• Retraso: CrUX lleva aproximadamente 2 días de retraso; las correcciones suelen registrarse en torno a un mes, pero no hay una garantía fija de 30 días: depende del tráfico apto y de la métrica.
• Cobertura: solo experiencias aptas de Chrome (activación voluntaria, sincronización y plataforma compatible), nunca todos los usuarios de Chrome ni todos los visitantes. Sin Chrome en iOS, sin WebViews ni Edge / Safari / Firefox.
• ¿Sin datos? La cascada es nivel de URL → nivel de origen → solo laboratorio (Lighthouse). Un resultado ausente significa «muestra apta insuficiente», no cero ni aprobado. La elegibilidad de página y origen se evalúa por separado.
• Campo frente a laboratorio: CrUX = campo (usuarios reales, lo que evalúa Google). Lighthouse = laboratorio (una carga simulada, para depurar).

Umbrales de CWV (en p75)

Herramientas para trabajar con CrUX

• PageSpeed Insights (pagespeed.web.dev): comprobación de campo por URL más rápida; CrUX arriba y laboratorio de Lighthouse abajo. Gratis y sin clave.
• Search Console — informe de Core Web Vitals: evaluación de CrUX de todo el sitio agrupada por estado y separada entre móvil y escritorio. La mejor vista del estado de sus CWV reales.
• CrUX Vis (cruxvis.withgoogle.com): herramienta gratuita de tendencias visuales sobre la API de History; nivel de origen y URL; hasta 40 semanas. Sustituye al CrUX Dashboard obsoleto.
• API de CrUX (chromeuxreport.googleapis.com/v1/records:queryRecord): datos actuales de 28 días por programa; diaria; necesita una clave gratuita de Google Cloud para la «Chrome UX Report API».
• API de History de CrUX (…:queryHistoryRecord): instantáneas semanales, hasta 40 semanas, con la misma autenticación y los mismos límites de velocidad que la API de CrUX.
• CrUX en BigQuery (conjunto de datos chrome-ux-report): investigación a escala, nivel de origen, mensual (segundo martes), nivel de país e historial hasta 2017; nivel gratuito.
• Chrome DevTools — panel Performance: muestra datos de campo de CrUX junto a su traza local (añadido en marzo de 2025), para comparar laboratorio y campo lado a lado.

¿Qué superficie de CrUX debería usar?

Errores de CrUX que llevan a malas decisiones

Tratar una reserva a nivel de origen como evidencia a nivel de página

PageSpeed Insights puede pasar de una URL a su origen cuando las muestras son escasas. Lea el alcance que se muestra antes de afirmar que una página concreta aprueba; use datos a nivel de URL cuando estén disponibles y etiquete honestamente los datos de origen cuando no lo estén.

Esperar que una corrección del día del lanzamiento reescriba una ventana de 28 días

CrUX es un conjunto de datos de campo móvil, no una prueba de despliegue en directo. Use datos de laboratorio o RUM para los diagnósticos iniciales y después espere a que nuevas experiencias sustituyan la ventana de campo antigua.

Llamar medición de CrUX a una medición de Lighthouse

Lighthouse es una ejecución de laboratorio controlada. CrUX agrega visitas reales aptas de Chrome. Use Lighthouse para diagnosticar una causa probable, no para declarar corregida la evaluación de campo de Google.

Suponer que CrUX representa a todos los usuarios

CrUX excluye Safari, Firefox, Edge, Chrome en iOS, WebViews y los usuarios de Chrome que no cumplen las reglas de elegibilidad. Compárelo con un RUM de primera parte cuando la mezcla de audiencia pueda hacer que la muestra de Chrome no sea representativa.

PageSpeed Insights dice que no hay datos de campo

Síntoma: falta la sección de campo. Causa probable: ni la URL ni su origen cumplen los requisitos de elegibilidad o de muestra de CrUX. Solución: confirme que la página pública devuelve 200 y es indexable; después use datos de laboratorio o RUM de primera parte. El tráfico no se puede fabricar para CrUX. Vuelva a comprobarlo más adelante si crece el uso real.

La página parece buena, pero el origen parece malo

Síntoma: los resultados a nivel de URL y de origen no coinciden. Causa probable: el origen agrega muchos tipos de página con distinto rendimiento. Solución: conserve el alcance en su informe, inspeccione URL representativas de las plantillas lentas y evite promediar ambos registros.

Lighthouse aprueba mientras Search Console falla

Síntoma: una prueba controlada aparece en verde, pero el informe de CWV no. Causa probable: los usuarios reales tienen dispositivos, redes, estados de caché o interacciones más lentos que la ejecución de laboratorio. Solución: segmente CrUX por dispositivo, compare la métrica de campo y la de laboratorio una por una, y use la traza de laboratorio para reproducir el cuello de botella de campo.

Una consulta de API devuelve «no encontrado»

Síntoma: una consulta de URL/factor de forma no tiene registro. Causa probable: la combinación más específica tiene muy pocas experiencias aptas. Solución: elimine dimensiones opcionales, pruebe el alcance de origen e informe explícitamente de la reserva en lugar de tratar los datos ausentes como un resultado aprobado.

Lista de comprobación del análisis de CrUX

• Registre si cada valor es de nivel de URL o de nivel de origen.
• Mantenga separados los resultados móviles y de escritorio/factor de forma.
• Confirme que la ventana es la de los 28 días anteriores y anote las fechas de recopilación.
• Lea p75 como un percentil de cargas de página, no como la puntuación de un usuario individual.
• Compruebe si PageSpeed Insights recurrió de la URL al origen.
• Trate los datos ausentes como cobertura insuficiente, nunca como aprobado.
• Compare LCP, INP y CLS por separado; una métrica aprobada no hace que todas lo estén.
• Use Lighthouse o DevTools para diagnosticar, no como sustituto de los datos de campo.
• Compare CrUX con RUM de primera parte cuando los usuarios que no usan Chrome sean importantes.
• Deje que la ventana móvil cambie antes de juzgar una corrección de producción en CrUX.

Alcance, ventana, percentil y población

Cada número de CrUX resulta más fácil de interpretar cuando etiqueto primero cuatro cosas:

1. Alcance: ¿es la URL exacta o todo el origen?
2. Ventana: ¿qué periodo móvil de 28 días lo produjo?
3. Percentil: es p75, no un promedio ni la visita de un usuario.
4. Población: usuarios aptos de Chrome en plataformas compatibles, no todo el tráfico.

Si un informe omite cualquiera de esos datos, es fácil exagerar la cifra.

Primero el veredicto, después el diagnóstico

CrUX responde qué experimentaron los usuarios reales aptos. Una traza de laboratorio responde por qué una carga controlada se comportó así. Empiece por el veredicto de campo, elija la métrica y el alcance afectados y después use herramientas de laboratorio para investigar. Tras publicar una corrección, use el laboratorio para confirmar inmediatamente el mecanismo y CrUX para confirmar el resultado a nivel de población cuando cambie la ventana móvil.

KPI continuos de CrUX

LCP, INP y CLS en p75

Métrica: cada Core Web Vital en p75. Qué le indica: la experiencia de campo que Google usa para su evaluación de CWV. Cómo obtenerla: API de CrUX, API de History, CrUX Vis o PageSpeed Insights, registrando el alcance y el factor de forma. Referencia / rango realista: use los umbrales Good publicados en este artículo; mantenga separadas las tres métricas. Cadencia: tendencias semanales, con comprobaciones diarias durante un despliegue.

Cobertura del estado Good por plantilla

Métrica: proporción de grupos de URL importantes evaluados como Good en Search Console. Qué le indica: hasta qué punto el rendimiento de campo es saludable en todo el sitio. Cómo obtenerla: informes de Core Web Vitals para móvil y escritorio más un inventario de plantillas. Referencia / rango realista: establezca una línea base del sitio y dé prioridad a las plantillas valiosas y con mucho tráfico; las URL escasas pueden no tener un registro individual de CrUX. Cadencia: semanal.

Disponibilidad de datos a nivel de URL

Métrica: URL prioritarias monitorizadas con su propio registro de CrUX en lugar de una reserva al origen. Qué le indica: cuánta evidencia específica de página puede respaldar su informe. Cómo obtenerla: registre el éxito de las consultas a la API y el alcance de PSI para el conjunto fijo de URL. Referencia / rango realista: depende del tráfico apto de Chrome; no convierta la cobertura en un objetivo que fomente tráfico artificial. Cadencia: mensual.

Póngase a prueba: Chrome UX Report

Cinco preguntas rápidas sobre el alcance, la cobertura y la interpretación de CrUX. Elija una respuesta para cada una y después compruébelas.

Recursos que merecen su tiempo

Mis artículos relacionados

• Estudio de datos de Core Web Vitals con CrUX y 5,2 millones de páginas: mi estudio de primera mano que combina CrUX con un rastreo de 43,66 millones de páginas; fuente de las cifras de cobertura de aproximadamente el 11,9 % y de las tasas de aprobación de origen frente a página.
• Qué son los Core Web Vitals: dónde encaja CrUX y mi opinión sobre cuánto mueven realmente los CWV el posicionamiento.
• Largest Contentful Paint (LCP): el marco de datos de campo para LCP.
• Cumulative Layout Shift (CLS): incluye por qué la ventana de 28 días ralentiza la mejora visible.
• Guía de PageSpeed Insights: la herramienta que muestra los datos de campo de CrUX por URL.

Oficial

• Documentación de CrUX (equipo de Chrome): la referencia canónica de todo lo anterior.
• Informe CrUX de HTTP Archive: paneles públicos continuos basados en CrUX/BigQuery.

De otros

• Guía del Chrome User Experience Report de DebugBear: comparación exhaustiva de herramientas, orientada a desarrolladores.
• Guía de Lumar sobre SEO, velocidad del sitio, CWV, Lighthouse y CrUX: un marco sólido de SEO.
• Cuándo usar CrUX, RUM y monitorización sintética de SpeedCurve: comparación honesta de las tres opciones, con el punto ciego de Chrome-only/iOS claramente señalado.
• Qué es CrUX y por qué debería importarme, de GTmetrix: desglose detallado de elegibilidad y cobertura.

Estadísticas que vale la pena citar

• Solo aproximadamente el 11,9 % de las 43,66 millones de páginas únicas de Site Audit de mi muestra de enero de 2022 tenía al menos una métrica de Core Web Vitals de CrUX. Eran 5,21 millones de páginas; el resto tenía demasiado poco tráfico para cumplir los requisitos. Fuente
• Las tasas de aprobación de origen superaron a las de página en esa misma muestra de enero de 2022: aproximadamente 33 % frente a 21,2 %. Los dominios que aprobaban los CWV a nivel de origen tenían una proporción muy superior a la de páginas individuales aprobadas; los promedios de origen incorporan páginas más rápidas y visitas repetidas en caché. Una instantánea fechada, no una tasa universal actual. Fuente
• Casi ningún sitio en 3G o conexiones más lentas aprobó los CWV, según ese estudio. “The LCP threshold seems almost impossible to pass on slower connections.” (traducción) «El umbral de LCP parece casi imposible de superar en conexiones más lentas». Fuente
• La geografía sesgó los resultados de esa muestra. Estados Unidos ocupó el puesto 38 a escala mundial, con una tasa de aprobación de aproximadamente el 41 %; las normas de dispositivo y red de cada país explicaban la mayor parte de la diferencia. Fuente
• Se tarda aproximadamente un mes en que una corrección se registre por completo: la ventana de 28 días más el retraso aproximado de 2 días de CrUX, aunque el plazo exacto no es fijo y depende del tráfico apto y de la métrica implicada. Fuente
• Más de la mitad de los orígenes aprueba ahora Core Web Vitals. En el hito de CrUX de agosto de 2024, Google informó de que más del 50 % de los orígenes del conjunto de datos aprobaba los tres Core Web Vitals, un aumento significativo frente a la tasa de aprobación de origen de aproximadamente el 33 % medida en estudios anteriores. Fuente
• CrUX cubre más de 15 millones de orígenes. En 2024–2025, el conjunto de datos incluía datos de más de 15 millones de orígenes distintos, según la documentación de metodología del equipo de Chrome. Fuente

Registro de cambios