Lighthouse vs field data: comprueba que el fix funcionó

Lighthouse dice que está arreglado. ¿Por qué Search Console sigue en rojo?

Lighthouse carga la página una vez, en un móvil simulado, y muestra el LCP y el CLS de esa carga. Los Core Web Vitals son field data: el percentil 75 de 28 días de visitas reales en Chrome, en móviles y redes rápidos y lentos, con la caché vacía o llena, e incluyendo cada clic. Por eso un fix puede pasar hoy en Lighthouse y tardar cuatro semanas en verse en Search Console. Compara tres ejecuciones de Lighthouse y luego vigila el field data.

¿Cómo ejecutas Lighthouse para poder comparar el antes y el después?

Ejecuta Lighthouse de la misma forma antes y después del cambio:

1. Limpia las cachés. Vacía la caché del plugin de caché y de la CDN después del cambio, o Lighthouse probará la página antigua.
2. Elige una herramienta y no la cambies. Sin código: PageSpeed Insights, en la pestaña Mobile. Como desarrollador: el panel de Lighthouse en Chrome DevTools con Device en Mobile, en una ventana de incógnito, porque las extensiones del navegador añaden sus propios scripts a la página.
3. Prueba la URL que tenía el aviso. Si el cambio fue en la plantilla de producto, prueba una página de producto.
4. Ejecútalo tres veces y quédate con el resultado intermedio.
5. Fíjate primero en el aviso y en su métrica. El aviso pasa a Passed audits y la métrica afectada (LCP, CLS, Total Blocking Time) baja. La puntuación va al final.

¿Por qué cambia la puntuación si no ha cambiado nada?

Cada ejecución es una carga, y no hay dos cargas iguales: el servidor responde más rápido o más despacio, la red varía, y los anuncios, banners de consentimiento y tests A/B pueden cambiar de una pasada a otra. En una de mis páginas de prueba, el primer texto o imagen (FCP) apareció 1,5 s antes en una ejecución que en otra, y en una segunda página la puntuación dio 96 u 80 sin haber cambiado nada. Que la puntuación suba unos puntos tras un fix no te dice casi nada hasta que no comparas el resultado intermedio de tres ejecuciones.

Seis ejecuciones seguidas en la misma URL, www.bbc.com, dieron 38, 44, 41, 73, 60 y 53 en menos de dos minutos. Lighthouse 13.5.0, móvil, throttling simulado como en PageSpeed Insights.

Cómo grabar un trace en DevTools

Abre la página en Chrome, abre DevTools y ve al panel Performance. En Capture settings (el icono del engranaje), pon Network en Slow 4G y CPU en 4x slowdown, algo muy parecido a lo que simula Lighthouse en móvil; luego haz clic en Record y recarga. La pestaña Insights de la barra lateral muestra los mismos insights que Lighthouse, cada uno con las requests y los elementos que tiene detrás. Antes de grabar, el panel muestra el LCP, el CLS y el INP en tiempo real (el INP en cuanto haces clic en la página). Haz clic en Set up debajo de Field metrics y te pondrá al lado las cifras de CrUX de las visitas reales para esa misma URL.

¿Por qué Lighthouse dice una cosa y Search Console otra?

Lighthouse te da lab data: una sola carga de la página en un móvil de gama media simulado sobre una conexión 4G lenta y con la caché vacía. Se detiene poco después de la carga, así que nunca hace scroll, ni toques en la pantalla, ni abre una segunda página. Obtienes el LCP y el CLS de esa única carga, y nada de INP, porque el INP necesita un visitante que haga clic.

El field data es lo que Chrome midió para los visitantes reales: móviles rápidos y lentos, redes buenas y malas, una primera visita con la caché vacía y la décima con todo en caché, haciendo scroll, tocando la pantalla y pasando de una página a otra. Google lo recopila en el Chrome UX Report (CrUX), a partir de usuarios de Chrome en Android y desktop que comparten estadísticas de uso. Los Core Web Vitals son esas visitas durante los últimos 28 días, por métrica en el percentil 75 (p75): tres de cada cuatro visitas fueron al menos así de buenas.

Google posiciona con el field data. Lighthouse sirve para averiguar por qué una página es lenta y si un cambio ayuda. Cuando ambos no coinciden, es porque midieron cargas distintas. Una puntuación verde en Lighthouse con un mal field data suele deberse a móviles más lentos que la simulación, respuestas lentas a los clics (INP) o contenido que se desplaza mientras los visitantes hacen scroll. Una puntuación roja con buen field data suele indicar que los visitantes tienen móviles y redes más rápidos que el 4G lento de Lighthouse, y que vuelven con los archivos guardados en caché.

Un informe de PageSpeed Insights para www.bbc.com en móvil, 26 de octubre de 2026. Las visitas reales aprueban los tres Core Web Vitals con un LCP de 1,2 s; la ejecución de Lighthouse en el mismo informe saca un 37 con un LCP de 9,5 s.

PageSpeed Insights muestra el field data de la URL analizada si tiene suficientes visitas, y de todo el sitio en Origin cuando no llega al mínimo. Search Console agrupa las URLs similares y evalúa cada grupo por su peor métrica.

¿Dónde ves lo que experimentaron los visitantes?

Cuatro herramientas gratuitas muestran CrUX, el field data que utiliza Google:

• PageSpeed Insights: la sección superior, «Descubre qué experimentan tus usuarios reales», con LCP, INP y CLS en el p75 de los últimos 28 días, para la URL o el origin.
• Search Console: el informe de Core Web Vitals, para móvil y ordenador, muestra qué grupos de URLs similares tienen un rendimiento pobre en todo el sitio.
• CrUX History report: una barra por semana para el sitio o una URL, para ver la tendencia.
• DevTools: el panel Performance coloca las mismas cifras junto a tu propia carga (se configura una sola vez).

Un sitio con muy pocas visitas en Chrome no tiene datos de CrUX: PageSpeed Insights muestra «No Data» en la sección superior. CoreDash mide esas visitas de todos modos.

CoreDash: qué página, qué elemento

CrUX, el field data de Google, da un único p75 por URL o por sitio. CoreDash, la herramienta de real user monitoring que desarrollé, es un script en tus páginas que mide cada visita e identifica el elemento detrás de cada LCP, INP y CLS. Puedes filtrar por página, dispositivo y elemento, y cualquier cambio se refleja en la serie temporal a partir de las siguientes visitas. Añade el script antes de cambiar nada para poder comparar el antes y el después.

CoreDash, acme-pagespeed.com, móvil, p75 por página: una página tiene un CLS de 0,92 mientras el resto tiene 0.

¿Cuánto tarda Search Console en mostrar el fix?

PageSpeed Insights y Search Console muestran los últimos 28 días, y esa ventana se desplaza a diario. En PageSpeed Insights los datos tienen un retraso de unos dos días; en Search Console, algunos días más. Dos semanas después del fix, la mitad de las visitas de esa ventana siguen siendo anteriores al fix. A las cuatro semanas, solo contiene visitas posteriores al fix. En la ventana de 28 días, día a día tienes la cronología completa.

Search Console, informe de Core Web Vitals, móvil, a 26 de octubre de 2026: última actualización el 21 de octubre.

El CrUX History report muestra esa misma ventana por semanas: cada barra abarca los 28 días anteriores, por lo que un fix tarda unas cuatro barras en reflejarse por completo.

CrUX History report para ado-goldkante.de, móviles, LCP: proporción de cargas buenas, necesitan mejorar y pobres por semana. Tras un cambio a mediados de agosto, la proporción buena sube del 59 % a lo largo de cuatro barras al 76 %, 83 %, 90 % y 93 %, y el p75 de LCP pasa de 3,6 s a 1,5 s.

Cuando el fix esté en producción, abre la incidencia en el informe de Core Web Vitals de Search Console y haz clic en Start Tracking (también llamado Validate fix). Eso inicia la comprobación de 28 días de Search Console para cada URL con esa incidencia, con el mismo field data. Mientras se ejecuta, el estado es Started, y pasa a Looking good en cuanto todas las URLs revisadas hasta el momento están bien. Termina en Passed cuando ninguna URL ha tenido el problema durante 28 días, o en Failed si todavía queda alguna; en ese caso, lo solucionas y haces clic en Start new validation.

¿Cómo sabes si un fix ha funcionado con los visitantes reales?

Comprueba en este orden, de más rápido a más lento:

1. El cambio está en producción. Mira el código fuente o busca el archivo o la cabecera en el panel Network de DevTools. Si sigues viendo la versión anterior, un plugin de caché o la CDN están sirviendo la página vieja.
2. Lighthouse aprueba. Móvil, tres ejecuciones, el resultado intermedio (como vimos arriba): el aviso pasa a Passed audits.
3. Llega a los visitantes. En CoreDash, a partir de las siguientes visitas: filtra la página o plantilla modificada, selecciona móvil en el dispositivo y sigue la métrica por día y el elemento que la causa.
4. CrUX le sigue. El field data de PageSpeed Insights y las barras del CrUX History report se mueven poco a poco. El impacto total se aprecia a las cuatro semanas (por qué tarda tanto).
5. Search Console lo confirma. En el informe de Core Web Vitals, haz clic en Start Tracking en la incidencia y espera a Passed.

¿Lighthouse aprueba, han pasado cuatro semanas y el field data sigue sin moverse? Entonces las visitas lentas corresponden a casos que Lighthouse nunca prueba: un móvil más barato, un clic lento o un salto de contenido a mitad de página. En una Core Web Vitals power hour reviso el field data contigo, grupo de páginas por grupo de páginas, hasta averiguar qué página y qué elemento están frenando el p75.