Guía de Core Web Vitals

Core Web Vitals no es un único score de velocidad. Es un conjunto de field metrics que mide experiencia real de usuario sobre dispositivos, redes y sesiones reales. Por eso una página puede lucir excelente en Lighthouse o PageSpeed Insights y seguir fallando en campo para una parte significativa de su audiencia móvil.

El conjunto actual se apoya en tres métricas: LCP para carga percibida, INP para capacidad de respuesta y CLS para estabilidad visual. Google evalúa estas señales en el percentil 75 de cargas reales, así que importa el comportamiento consistente, no solo el mejor caso ni la mediana.

Qué miden realmente Core Web Vitals

Core Web Vitals sustituyó métricas anteriores como First Contentful Paint, First Meaningful Paint y First Input Delay porque esas señales no capturaban de forma fiable si el usuario percibía una página como rápida, estable y reactiva. El conjunto actual aborda tres dimensiones distintas de la experiencia.

Largest Contentful Paint (LCP) mide rendimiento de carga, en concreto el momento en que el elemento visible más grande del viewport termina de renderizarse. Es la métrica que mejor se correlaciona con la sensación de que la página ya cargó.

Interaction to Next Paint (INP) mide la capacidad de respuesta de una interacción, es decir, la latencia entre una acción del usuario y la siguiente actualización visual. INP sustituyó a FID como Core Web Vital en marzo de 2024 porque FID solo medía la primera interacción, mientras que INP captura el ciclo completo de interacción a lo largo de la visita.

Cumulative Layout Shift (CLS) mide estabilidad visual. Calcula la puntuación acumulada de todos los cambios inesperados de layout durante la vida útil de la página. Un shift ocurre cuando un elemento visible cambia de posición sin que el usuario lo haya provocado.

Los umbrales son claros: LCP debería estar por debajo de 2,5 segundos para una calificación Good, INP por debajo de 200 milisegundos y CLS por debajo de 0,1. Estos umbrales aplican al percentil 75 de cargas reales para una URL, no a la mediana.

Largest Contentful Paint (LCP)

LCP mide cuándo termina de renderizarse el elemento de contenido más grande del viewport, normalmente una imagen hero, un bloque de texto grande o el póster de un vídeo. Está diseñado para correlacionarse con la percepción de que el contenido principal ya es visible y usable.

LCP depende de cuatro subprocesos secuenciales, y cualquiera de ellos puede convertirse en el cuello de botella dominante.

La optimización depende de cuál de esos subprocesos esté limitando el resultado. Intervenciones frecuentes son priorizar el recurso LCP con fetchpriority igual a high, eliminar scripts render-blocking por encima del fold, reducir TTFB con CDN, servir imágenes en dimensiones correctas y formatos como WebP o AVIF, y retirar terceros que compiten por tiempo de main thread al inicio de la carga.

Interaction to Next Paint (INP)

INP sustituyó a First Input Delay como Core Web Vital en marzo de 2024. La diferencia es importante: FID solo medía la espera antes de que el navegador empezara a procesar la primera interacción. INP mide la latencia completa, desde la interacción hasta la siguiente actualización visual, a lo largo de toda la visita.

Ese cambio hace que INP sea bastante más difícil de aprobar que FID en páginas con comportamiento complejo en cliente. Una página podía pasar FID con una carga inicial limpia y, aun así, sufrir problemas graves de respuesta en interacciones posteriores. Esos fallos quedaban ocultos para FID y son visibles con INP.

Un INP deficiente suele aparecer cuando el comportamiento del frontend acumula trabajo pesado en JavaScript, bloquea el main thread o hace que la actualización visual llegue tarde respecto a la interacción.

Mejorar INP suele requerir profiling y refactorización de JavaScript. Es un trabajo más técnico que muchas optimizaciones de LCP, que a menudo se resuelven con decisiones de infraestructura y entrega de assets.

Cumulative Layout Shift (CLS)

CLS mide inestabilidad visual, es decir, cuánto se desplazan elementos visibles de forma inesperada durante el ciclo de vida de la página. Un valor de 0 significa que no hubo shifts. Por encima de 0,1 se considera Needs Improvement y por encima de 0,25 se considera Poor.

Los shifts suelen venir de medios sin espacio reservado, inserciones tardías de contenido, componentes que cambian de tamaño después del render o dependencias que alteran el layout sin previsibilidad.

Para depurar CLS en Chrome DevTools, la superposición de Layout Shift en el panel Rendering muestra qué elementos se movieron y cuándo. El track Experience del panel Performance añade los eventos con sus impact fractions y distance fractions, que determinan la contribución final al score.

Infraestructura de medición

Aprobar Core Web Vitals requiere dos sistemas distintos de medición: herramientas de laboratorio para diagnosticar y herramientas de campo para conocer la verdad operativa. Optimizar solo con datos de laboratorio produce mejoras que no necesariamente cambian el rendimiento real que afecta al ranking.

Chrome User Experience Report o CrUX es la fuente de field data para Core Web Vitals en Google Search Console y PageSpeed Insights. Agrega mediciones reales de usuarios de Chrome y ofrece datos a nivel de URL y de origen, siempre que exista un umbral mínimo de tráfico.

PageSpeed Insights combina dos fuentes: datos de campo de CrUX y una simulación de laboratorio con Lighthouse. La puntuación de laboratorio no predice por sí sola el comportamiento en campo.

El informe de Core Web Vitals en Search Console agrupa URLs por estado y señala qué métrica está causando el fallo. Es la vista de field data más accionable para una remediación sistemática.

Real User Monitoring o RUM resulta clave cuando una organización necesita más granularidad que la que ofrece CrUX, ya sea por segmento, por dimensión propia o por la necesidad de feedback inmediato en lugar de ventanas móviles de 28 días.

Lighthouse sigue siendo una herramienta de laboratorio muy valiosa para encontrar qué corregir, pero CrUX y Search Console son los instrumentos correctos para validar si una corrección ha mejorado el rendimiento real.

El trabajo de SEO técnico y visibilidad GEO de Logic Grid Studio incluye auditoría y remediación de Core Web Vitals: establecer líneas base de campo, detectar la métrica y el subcomponente responsables del fallo y acotar los cambios de ingeniería necesarios para llevar a estado Good los grupos de URLs que importan para la visibilidad orgánica.