¿Qué muestra este informe de Core Web Vitals?
Introduce un dominio o una URL, elige móvil o desktop y el informe extrae 25 semanas de field data de la CrUX History API de Google. Obtienes un gráfico semanal para el LCP, el INP y el CLS, además del TTFB y el FCP. El LCP nunca puede ser más rápido que ninguno de los dos. Funciona con cualquier sitio que tenga suficiente tráfico de Chrome, también con el de un competidor.
Debajo de los gráficos de carga, el LCP se divide en sus cuatro partes. Más abajo encuentras el CLS y el INP a lo largo del tiempo, y después los dispositivos y los tipos de navegación. Estos dos últimos, y el desglose de imagen o texto del LCP, son para todos los dispositivos juntos, elijas la opción que elijas.
Cómo leer los gráficos semanales de CrUX
Una barra es una semana. Pasa el cursor por encima para ver el p75 de esa semana y la proporción de cargas de página buenas, que necesitan mejora y deficientes.
El p75 es la cifra por la que Google te juzga: tres de cada cuatro cargas de página fueron al menos así de buenas.
- El LCP es bueno hasta 2,5 s y deficiente por encima de 4 s
- El INP es bueno hasta 200 ms y deficiente por encima de 500 ms
- El CLS es bueno hasta 0,1 y deficiente por encima de 0,25
Apruebas los Core Web Vitals cuando los tres son buenos en el p75.
El badge de cada tarjeta de métrica muestra la dirección de una línea recta trazada a lo largo de todas las semanas. El resumen superior compara el p75 medio de la mitad más antigua de las semanas con el de la más reciente. La puntuación de UX happiness de al lado es una cifra propia: el porcentaje de cargas de página buenas en la última semana, calculando la media de LCP, INP, CLS, FCP y TTFB. Google no la usa y, de todos modos, no hay ninguna puntuación oficial de Core Web Vitals.
¿De dónde vienen los datos de CrUX?
De Chrome en Android y desktop, de usuarios que sincronizan su historial y comparten estadísticas de uso con Google. Chrome en iPhone no está incluido. Edge tampoco.
Cada punto semanal cubre los 28 días anteriores, así que los puntos se solapan. Un fix que sale a producción un martes tarda unos cuatro puntos en verse por completo.
Google añade un punto nuevo cada lunes con datos hasta el sábado anterior; así, el lunes el punto más reciente tiene dos días. Los 28 días indican el ancho de cada ventana, y por eso el retraso de 28 días es un mito.
Esto es lo que experimentaron los visitantes en sus propios dispositivos. PageSpeed Insights ejecuta Lighthouse una sola vez, desde un servidor de Google y simulando un móvil y una red lentos. Lighthouse nunca hace clic en nada, así que no tiene INP en absoluto. Un 98 en Lighthouse y una línea roja de INP aquí pueden ser ciertos a la vez.
¿En qué se diferencia del informe de Core Web Vitals en Search Console?
Search Console lee los mismos datos de CrUX, pero solo para tus propios sitios. Agrupa las URL con un comportamiento similar y etiqueta cada grupo según su peor métrica en los últimos 28 días.
Search Console te dice qué grupo de páginas falla. Las barras semanales de aquí te ayudan a localizar la semana en que empezó y, a partir de ahí, la release.
Qué revisar cuando una métrica empeora
Quédate primero en móvil (el informe se abre ahí): casi siempre es el peor de los dos. Luego mira la forma de la línea.
Un deploy se ve como una subida a lo largo de unas cuatro semanas que luego se estabiliza: un tema nuevo, una etiqueta añadida en Tag Manager o una imagen hero a la que se le puso loading="lazy". Revisa qué salió a producción la semana en que empieza la subida.
Una línea que no para de subir durante meses suele deberse a la acumulación de scripts de terceros.
Para el LCP, abre el gráfico de desglose y mira qué parte ha crecido. Solo cuenta las cargas de página donde el elemento del LCP es una imagen. Un TTFB más alto apunta al servidor o a la caché. Un load delay más largo significa que el navegador encuentra la imagen del LCP tarde. Un load duration más largo indica una imagen más pesada o una conexión lenta con el servidor donde está alojada. Un render delay al alza significa que el CSS o el JavaScript están frenando el render.
Lo que el historial de CrUX no te dice
Los sitios pequeños no tienen datos. Google necesita muchas visitas desde Chrome y no dice cuántas. Las páginas con noindex o con un status distinto de 200 también quedan fuera. ¿La URL sale vacía? Prueba con el dominio completo. El informe prueba con y sin www por ti.
Incluso con datos, obtienes un solo p75 por métrica y semana para todo el dominio o para una URL popular. CrUX no te dice qué plantilla es lenta, qué elemento se mueve ni qué script retrasa el clic.
Para eso hace falta RUM en tu propio sitio. Creé CoreDash para eso: las cargas de página en tu propio sitio, con el elemento del LCP y la interacción lenta vinculados, para que veas funcionar un fix en cuestión de horas.