Lighthouse, CrUX y RUM: qué datos de Core Web Vitals usar

Usa CrUX para saber si el sitio aprueba las Core Web Vitals y para decidir qué atacar primero: son los datos de usuarios reales de Chrome que Google usa en la Búsqueda. Usa Lighthouse (o la parte de laboratorio de PageSpeed Insights) para reproducir un problema y probar la corrección antes de publicar. Usa un RUM propio cuando necesites ver cada visita, cada página y la causa de una cifra mala, con desgloses que CrUX no ofrece. La puntuación de 0 a 100 de Lighthouse no es una Core Web Vital y no decide la posición en Google.

Este artículo compara las tres fuentes. Para lo básico sobre las métricas y cómo mejorar cada una, consulta la guía de Core Web Vitals.

Cuáles son las Core Web Vitals hoy

Son tres métricas, todas con estado estable según web.dev:

• LCP (Largest Contentful Paint, o renderizado del contenido más grande) mide la carga. Es el tiempo hasta que aparece en pantalla la imagen, el bloque de texto o el vídeo visible más grande de la ventana (web.dev).

• INP (Interaction to Next Paint, o interacción hasta el siguiente renderizado) mide la respuesta a las acciones del usuario. Observa la latencia de clics, toques y teclas durante toda la visita y, en general, informa de la peor; en páginas con muchas interacciones, descarta la mayor de cada 50 para que los casos aislados no lo distorsionen. El desplazamiento, el hover y el zoom no cuentan, y quien no interactúa con la página no genera INP (web.dev).

• CLS (Cumulative Layout Shift, o cambio de diseño acumulado) mide la estabilidad visual. Los desplazamientos inesperados se agrupan en ventanas (con menos de 1 segundo entre ellos, hasta 5 segundos por ventana), y el CLS es la mayor de esas ventanas a lo largo de toda la vida de la página (web.dev).

El INP sustituyó al FID en marzo de 2024

El INP pasó a ser Core Web Vital estable en marzo de 2024, en lugar del FID (First Input Delay). En el mismo anuncio, Chrome empezó a retirar el FID y dio de plazo hasta el 9 de septiembre de 2024 a quien leía el FID de las API de CrUX y de PageSpeed Insights para migrar al INP (web.dev). La biblioteca web-vitals eliminó la función onFID() en la versión 5.0.0, de mayo de 2025 (changelog de web-vitals). Un informe que todavía trata el FID como Core Web Vital está desactualizado.

Los umbrales de "bueno" y la regla del percentil 75

Una página aprueba cuando el percentil 75 de las cargas, separado entre móvil y escritorio, queda dentro del umbral "bueno" en las tres métricas (web.dev). Dicho de otro modo: al menos tres de cada cuatro visitas tienen que tener una buena experiencia. PageSpeed Insights sigue la misma regla y solo aprueba la evaluación cuando los tres percentiles 75 son buenos (documentación de PageSpeed Insights).

Fuentes de los umbrales: PageSpeed Insights, LCP, INP, CLS, FCP y TTFB.

FCP y TTFB ayudan en el diagnóstico, pero no son Core Web Vitals

El FCP (First Contentful Paint, o primer renderizado con contenido) marca el momento en que aparece en pantalla la primera parte del contenido: texto, imagen, SVG o un canvas que no esté en blanco (web.dev). El TTFB (Time to First Byte, o tiempo hasta el primer byte) suma las redirecciones, el arranque del service worker, la consulta DNS, la conexión y la negociación TLS hasta que llega el primer byte de la respuesta (web.dev).

web.dev trata las dos como métricas de apoyo, útiles para entender un LCP alto (web.dev). El propio artículo sobre el TTFB dice que, como no es Core Web Vital, no es obligatorio quedar dentro del umbral "bueno", siempre que el TTFB no impida buenos resultados en las métricas que cuentan (web.dev). En CrUX, el TTFB todavía aparece como experimental: en la API se llama experimental_time_to_first_byte (CrUX API).

Tres fuentes de datos que responden a preguntas distintas

Laboratorio: Lighthouse y la parte de diagnóstico de PageSpeed Insights

Los datos de laboratorio (también llamados sintéticos) vienen de una carga simulada en un entorno controlado. En PageSpeed Insights, esa parte la hace Lighthouse: en móvil simula un dispositivo de gama media en una red móvil; en escritorio, un ordenador con conexión por cable (PageSpeed Insights). Es una sola carga, con un dispositivo y una red fijos.

Lighthouse no mide el INP, porque nadie hace clic en la página. El sustituto en laboratorio es el TBT (Total Blocking Time, o tiempo total de bloqueo), que mide cuánto tiempo queda bloqueado el hilo principal durante la carga (web.dev). Un TBT bueno no garantiza un INP bueno: deja fuera, por ejemplo, el retraso del toque (web.dev).

La puntuación de rendimiento, de 0 a 100, es una media ponderada de cinco métricas. Según los pesos que publica la documentación para Lighthouse 10, el TBT vale un 30 %, el LCP y el CLS un 25 % cada uno, y el FCP y el Speed Index un 10 % cada uno. Cada métrica se convierte en puntos con una curva log-normal obtenida de datos reales de HTTP Archive. La puntuación varía entre ejecuciones, y la documentación atribuye buena parte de esa variación a cambios en las condiciones de la prueba, no a Lighthouse en sí (documentación de Lighthouse).

Campo: Chrome UX Report (CrUX)

CrUX es el conjunto público de datos de usuarios reales de Chrome que mantiene el programa Web Vitals. Según Chrome, la Búsqueda de Google lo usa en el factor de clasificación de experiencia en la página (CrUX). Son los mismos datos que aparecen en la parte de campo de PageSpeed Insights y en el informe de Core Web Vitals de Search Console (ayuda de Search Console).

Solo entran los usuarios de Chrome que activaron el envío de estadísticas de uso, sincronizan el historial y no usan una frase de contraseña propia para cifrar la sincronización. Vale para Chrome en escritorio (Windows, macOS, ChromeOS y Linux) y en Android, incluidas Custom Tabs y WebAPK. Quedan fuera Chrome en iOS, las apps de Android que abren páginas en WebView y otros navegadores basados en Chromium, como Edge. Google no publica qué fracción de los usuarios cumple estos criterios (metodología de CrUX).

El origen y cada página tienen que poder descubrirse públicamente, con los mismos criterios de indexación de los buscadores (estado 200 después de las redirecciones, sin noindex), y ser "suficientemente populares". El número mínimo de visitantes no se publica (metodología de CrUX). Por eso las páginas con poco tráfico, las áreas con inicio de sesión y los entornos de pruebas se quedan sin datos de campo.

Los datos de origen reúnen todas las páginas del origen; los de URL muestran solo esa página (CrUX API). Cuando la URL no tiene datos suficientes, PageSpeed Insights muestra los del origen, y si tampoco los tiene el origen, no muestra datos de campo (PageSpeed Insights).

Los valores son una media móvil de los últimos 28 días, y cada forma de acceso se actualiza a un ritmo distinto:

• La CrUX API se actualiza cada día, hacia las 04:00 UTC, sin hora garantizada, y va unos dos días por detrás de la fecha actual (CrUX API).

• La CrUX History API se actualiza los lunes y guarda hasta 40 periodos semanales, cada uno con 28 días de datos (CrUX History API).

• BigQuery recibe una tabla al mes, publicada el segundo martes del mes siguiente, solo con datos de origen e historial desde 2017. Es la única forma de acceso con la dimensión de país (CrUX en BigQuery, comparación de herramientas).

RUM propio: medir cada visita en tu sitio

RUM (real-user monitoring, o monitorización de usuarios reales) es un script instalado en el sitio que mide las métricas en el navegador de cada visitante y envía los valores a un servidor tuyo o de un proveedor. Una forma de medir con las mismas reglas que Chrome es la biblioteca web-vitals, del equipo de Chrome, que según su README mide las métricas igual que Chrome y las herramientas de Google. Tiene las funciones onLCP, onINP, onCLS, onFCP y onTTFB y ocupa unos 3 KB con compresión brotli. La versión más reciente cuando se escribió este texto es la 6.2.3, del 5 de octubre de 2026 (changelog).

Lo que un RUM ofrece y CrUX no:

• Datos de cualquier página que tenga el script, incluidas las que no llegan al mínimo de tráfico de CrUX y las que no son públicas, sin esperar una ventana de 28 días.

• La causa de la cifra. La versión de atribución (web-vitals/attribution, unos 1,5 KB más) añade a cada métrica el elemento y las fases del tiempo. En el LCP vienen el selector del elemento y las cuatro partes del tiempo; en el INP, el elemento de la interacción, las tres fases y las entradas de Long Animation Frames (fotogramas de animación largos, que señalan los scripts implicados); en el CLS, el elemento que más se desplazó y en qué fase de la carga ocurrió (README de web-vitals).

• Desgloses por tipo de página, dispositivo, conexión, país o cualquier otro dato que envíes junto con la métrica (web.dev).

• Otros navegadores: onLCP, onINP, onFCP y onTTFB funcionan en Chromium, Firefox y Safari; onCLS, solo en Chromium (README de web-vitals).

La documentación señala algunas precauciones. Los datos se deben enviar en el evento visibilitychange, cuando la página queda oculta, con navigator.sendBeacon(), porque unload y beforeunload no son fiables. El CLS y el INP solo cierran su valor cuando la página se oculta, y la misma métrica se puede notificar más de una vez (README, web.dev). Para resumir, usa percentiles en lugar de medias (web.dev). Los banners de consentimiento y los bloqueadores sacan visitas de la muestra, a veces justo la primera carga, que suele ser la más lenta, y una tasa de muestreo demasiado baja distorsiona las cifras (web.dev).

SPA y navegaciones suaves: qué cambió en 2026

En las aplicaciones de una sola página (SPA), cambiar de ruta sin recargar la página es una navegación suave (soft navigation). Las API del navegador no trataban ese cambio como navegación, y CrUX no lo contaba (web.dev). Desde Chrome 151 se puede medir: una navegación suave se registra cuando hay una interacción del usuario, la URL cambia y algo se pinta en pantalla. web-vitals empezó a admitirlo en la versión 6.0.0, de julio de 2026, con la opción reportSoftNavs: true (README, changelog).

La propia biblioteca enumera las salvedades. La definición puede dar falsos positivos. El TTFB de una navegación suave sale como 0. Los elementos que siguen en pantalla entre rutas no cuentan para el LCP, porque no se vuelven a pintar. El INP y el CLS se reinician en cada navegación suave. Activar la opción cambia también la medición de la primera carga, y los navegadores fuera de Chromium siguen informando solo de cargas completas (README de web-vitals).

En CrUX, versiones experimentales de LCP, INP y CLS con navegaciones suaves (por ejemplo, experimental_interaction_to_next_paint_with_softnavs) empezaron a publicarse en octubre de 2026 en la API, en la History API y en BigQuery. Las Core Web Vitals estables no cambiaron. Chrome tiene previsto sacar las nuevas métricas del estado experimental en mayo de 2027, según los comentarios que reciba, y solo después Search Console empezará a usarlas. Según el anuncio, la diferencia se concentra en SPA con muchas navegaciones después de la primera; en la mayoría de los sitios, las cifras deberían cambiar poco o nada (web.dev, web.dev).

Comparación entre laboratorio, CrUX y RUM

Por qué la puntuación de Lighthouse no coincide con los datos de campo

web.dev enumera los motivos (web.dev):

• El laboratorio usa un dispositivo, una red y una ubicación. Tus usuarios usan muchos, y el percentil 75 de campo refleja esa mezcla.

• La prueba de laboratorio suele cargar la página con la caché vacía. Quien vuelve al sitio ya tiene archivos en caché y ve la página más rápido.

• El elemento LCP de la prueba puede no ser el mismo que ve el usuario. El tamaño de pantalla, la personalización y las pruebas A/B cambian cuál es el elemento más grande.

• En campo, el navegador deja de buscar elementos más grandes en cuanto el usuario se desplaza o interactúa, lo que puede dar un LCP menor.

• En campo, el CLS cuenta los desplazamientos durante toda la visita. El laboratorio capta casi solo lo que ocurre en la parte superior de la página durante la carga, y se pierde, por ejemplo, imágenes e iframes sin dimensiones que solo se cargan cuando el usuario se desplaza.

• Los anuncios segmentados y las pruebas A/B cambian lo que se carga para cada persona.

La recomendación de web.dev es usar los datos de campo para fijar prioridades y los de laboratorio para depurar y probar antes de publicar (web.dev).

Una buena puntuación en Lighthouse no garantiza posición en Google

Esto es lo que dice la Central de la Búsqueda de Google (experiencia en la página, Core Web Vitals en la Búsqueda):

• Los sistemas de clasificación usan las Core Web Vitals, pero no existe una única señal de experiencia en la página.

• Los buenos resultados en el informe de Search Console o en herramientas de terceros no garantizan que las páginas queden en lo más alto de la Búsqueda.

• La Búsqueda intenta mostrar el contenido más relevante, incluso cuando la experiencia en la página no es la ideal.

• Buscar una puntuación perfecta solo por SEO puede no ser el mejor uso de tu tiempo.

El informe de Core Web Vitals de Search Console sale de CrUX (ayuda de Search Console), no de la puntuación de Lighthouse. Lo que aparece ahí es la experiencia de los usuarios reales, no el resultado de una prueba de laboratorio.

Qué datos usar para cada decisión

La tabla de abajo es una recomendación nuestra, construida a partir de las características de cada fuente descritas arriba.

Cuándo no se aplica la tabla: si el sitio no tiene datos en CrUX y todavía no instalaste un RUM, el laboratorio es la única señal disponible. En ese caso, úsalo para encontrar problemas evidentes, sabiendo que no dice si los usuarios están dentro de los umbrales.

Cómo encontrar la causa de un LCP, un INP o un CLS malos

El camino que recomienda Google empieza en el campo y después pasa al laboratorio: si hay datos de CrUX, mira primero a los usuarios reales (web.dev); para el INP, recoge datos de campo, reproduce la interacción lenta en el laboratorio y solo entonces optimiza (web.dev). Abajo tienes el resumen de cómo se divide cada métrica. Cada una tiene un artículo propio con las correcciones.

LCP: las cuatro partes del tiempo

1. TTFB: desde el inicio de la carga hasta que llega el primer byte. Referencia de Google: alrededor del 40 % del LCP.

2. Retraso de carga del recurso: desde el TTFB hasta que el navegador empieza a descargar el recurso del LCP (la imagen, por ejemplo). Menos del 10 %.

3. Duración de la carga del recurso: el tiempo que tarda en descargarse ese recurso. Alrededor del 40 %.

4. Retraso de renderizado del elemento: desde el final de la descarga hasta que el elemento aparece por completo. Menos del 10 %.

web.dev llama a estas proporciones referencia, no regla (web.dev). La CrUX API ya incluye, para los LCP de imagen, estas cuatro partes y el tipo de recurso del LCP; BigQuery no tiene esos datos (CrUX API, comparación de herramientas). Las correcciones de cada parte están en cómo mejorar el LCP.

INP: las tres fases de la interacción

1. Retraso de entrada: desde el momento de la interacción hasta que los callbacks del evento empiezan a ejecutarse. Crece cuando el hilo principal está ocupado con otros scripts.

2. Tiempo de procesamiento: cuánto tardan en terminar los callbacks del evento.

3. Retraso de presentación: desde el final de los callbacks hasta que el navegador pinta el siguiente fotograma con el resultado.

web.dev sugiere reproducir la interacción lenta en el laboratorio interactuando con la página durante la carga, cuando el hilo principal suele estar más ocupado (web.dev). En el RUM, la atribución de web-vitals indica la duración de cada fase y las entradas de Long Animation Frames ligadas a la interacción (README). El paso a paso está en cómo mejorar el INP.

CLS: el elemento que se mueve

Las fuentes más habituales, según web.dev, son las imágenes, los anuncios, las inserciones y los iframes sin dimensiones, el contenido inyectado después de la carga, las fuentes web y las animaciones de propiedades como top y left en lugar de transform. Los desplazamientos que ocurren hasta 500 ms después de un clic, un toque o una tecla se consideran esperados y no cuentan. Que la página sea apta para la caché de páginas completas (bfcache) evita que los desplazamientos se repitan cuando el usuario vuelve atrás (web.dev, web.dev).

Para encontrar el elemento: en campo, la atribución de web-vitals indica el elemento que más se desplazó; en laboratorio, el panel Performance de DevTools muestra los registros de desplazamiento, y Lighthouse enumera los elementos que se movieron y las imágenes sin ancho ni alto (web.dev). Más detalles en cómo corregir el CLS.

Por qué CrUX y RUM nunca coinciden exactamente

Aunque las dos fuentes miden usuarios reales, cubren poblaciones y ventanas distintas: CrUX es solo Chrome y solo usuarios que cumplen los requisitos; el RUM depende del consentimiento, del muestreo y del momento en que el script envía los valores. web.dev considera normales las diferencias pequeñas y sugiere, para comparar, filtrar el RUM por Chrome, el mismo tipo de dispositivo, el percentil 75 y una ventana de 28 días. Para el día a día, la orientación es mirar la tendencia después de cada cambio, sin esperar que las cifras coincidan (web.dev).

Recomendaciones prácticas

Lo que sigue es opinión nuestra, apoyada en los hechos de arriba.

1. Empieza por el informe de Core Web Vitals de Search Console o por la parte de campo de PageSpeed Insights. Son los datos que muestran si el sitio está dentro de los umbrales.

2. Si el sitio o las páginas que importan no tienen datos en CrUX, instala un RUM antes de dedicar tiempo a subir la puntuación de Lighthouse.

3. En el RUM, usa la versión de atribución de web-vitals y envía también el tipo de página (producto, categoría, artículo). Así puedes ver si el problema es de una plantilla de página entera o de una URL aislada. Para hacerlo en muchos sitios a la vez, consulta cómo monitorear el rendimiento de varios sitios.

4. Usa Lighthouse para probar correcciones, con más de una ejecución antes y después. Una ejecución aislada no basta para concluir nada.

5. Si el sitio es una SPA, el propio Google sugiere empezar ya a medir las Core Web Vitals por ruta (web.dev). Así ves antes lo que puede cambiar cuando las métricas con navegaciones suaves dejen de ser experimentales.

Estas recomendaciones no se aplican si necesitas la puntuación de Lighthouse por contrato o porque lo exige un cliente. En ese caso, la puntuación es el requisito, aunque no tenga efecto directo en la Búsqueda.

Cómo medir con WebVyze

El test de Core Web Vitals es gratis y muestra los datos de CrUX de los últimos 28 días, en móvil y escritorio, para hasta 10 URL. Los diagnósticos gratuitos de LCP, CLS e INP usan Google PageSpeed. Los planes de pago, a partir de Starter, incluyen un script de visitantes reales que mide LCP, INP y CLS de cada visita con la biblioteca web-vitals de Google y señala el elemento o la causa.