Informe de Core Web Vitals

Los datos de campo y los de laboratorio son cosas distintas

Una prueba de laboratorio, como Lighthouse, carga tu página una vez en un móvil simulado de gama media con una conexión limitada. Puedes repetirla tantas veces como quieras y está llena de detalle, pero el visitante que describe es imaginario.

Los datos de campo vienen de visitas reales. Los usuarios de Chrome que aceptaron compartir estadísticas de uso envían tiempos anónimos, y Google los agrega durante los últimos 28 días en el Chrome UX Report, conocido como CrUX. Son los datos que lee Google Search cuando evalúa la experiencia de página. Una página puede sacar 95 en el laboratorio y aun así suspender en el campo porque su público real usa móviles más viejos. También puede aprobar en el campo con una nota mediocre de laboratorio porque la mayoría de los visitantes llegan con la caché caliente.

Este informe pide primero los datos de campo, porque esa es la versión que cuenta.

Los cinco tiempos de la tabla

Los tres primeros son los Core Web Vitals. FCP y TTFB están como extras porque ayudan a explicar un LCP lento. No cuentan para la nota.

Cómo se construye el informe

Seguimos las redirecciones hasta la dirección final y luego consultamos CrUX dos veces, una para móviles y otra para ordenadores. Cada consulta prueba primero la página exacta y recurre a todo el origen cuando la página por sí sola tiene muy poco tráfico. La línea sobre cada tabla dice cuál de los dos estás leyendo.

El valor mostrado para una métrica es su percentil 75, es decir, tres de cada cuatro visitas fueron al menos así de rápidas. La barra de colores a su lado da la proporción de visitas en los rangos bueno, mejorable y malo.

Para la nota, cada Core Web Vital gana 2 puntos si es bueno, 1 si es mejorable y 0 si es malo. Seis puntos de seis es una A, cinco una B, cuatro una C, tres una D, dos una E y menos una F. Una sola métrica mala limita la nota a D, por buenas que sean las otras dos. La nota principal es la del móvil cuando hay datos de móvil.

Cuando Chrome no tiene datos

CrUX solo cubre páginas públicas y con suficientes visitas. Para todo lo demás, el informe ejecuta una prueba de PageSpeed Insights en un móvil simulado y te dice claramente que lo hizo. Entonces obtienes la puntuación de rendimiento de Lighthouse (A desde 90, B desde 75, C desde 50, D desde 35, E desde 20), valores de laboratorio para LCP y CLS, y Total Blocking Time en lugar de INP, porque no se puede medir la respuesta a una acción sin una persona que la haga. Debajo se listan hasta cinco auditorías con el mayor ahorro de tiempo estimado.

Qué mueve cada número

LCP

Encuentra el elemento LCP en el panel Performance de Chrome DevTools. Suele ser la imagen principal. Sírvela al tamaño en que se muestra, en WebP o AVIF, añade fetchpriority="high" y nunca le pongas loading="lazy". Si el TTFB ya supera 0.8 s, arregla primero el servidor con caché de páginas o un CDN. El desglose del tamaño de la página muestra los archivos más pesados.

INP

Las tareas largas de JavaScript impiden que la página responda a las acciones. Quita las etiquetas y los plugins que ya no uses, carga los scripts de terceros con defer y divide el trabajo que dure más de 50 ms.

CLS

Da a cada imagen y vídeo atributos width y height, reserva espacio para anuncios y contenidos incrustados con min-height o aspect-ratio, y no insertes banners encima de contenido que ya está visible.

Los datos de campo son una ventana móvil de 28 días. Después de una corrección, las cifras mejoran un poco cada día y tardan cuatro semanas en mostrar el efecto completo. Las visitas desde Safari y desde cualquier navegador en un iPhone nunca forman parte de CrUX, así que el informe solo describe a tu público de Chrome.