Core Web Vitals para principiantes: qué son y qué puedes corregir

Los Core Web Vitals son un conjunto de métricas que describen lo que vive una persona real en una página. Los define el equipo de Chrome y Google Search Central los incluye en su descripción de la experiencia de página. Son tres, y cada una cubre un aspecto distinto.

• LCP (Largest Contentful Paint) es el tiempo hasta que aparece el elemento visible más grande. Suele ser una imagen principal, el póster de un vídeo o un bloque grande de texto.
• INP (Interaction to Next Paint) mide con qué rapidez responde visualmente la página a clics, toques y pulsaciones de teclas durante toda la visita.
• CLS (Cumulative Layout Shift) suma los movimientos inesperados del contenido. Si un botón se desplaza justo cuando lo pulsas, es un mal CLS.

En marzo de 2024 el INP sustituyó al First Input Delay (FID) en el conjunto de Core Web Vitals. Si lees una guía antigua que cita el FID como tercera métrica, está desactualizada. Las definiciones están en web.dev y en la documentación de Google Search Central.

¿Por qué debería importarle a un propietario de sitio? Una página lenta o inestable molesta a los visitantes: se van antes de que termine de cargar o tocan donde no querían. Eso perjudica las conversiones, sea cual sea tu posición en las búsquedas.

Cada métrica tiene tres rangos: bueno, necesita mejorar y malo. Las cifras de abajo proceden de web.dev.

Una página aprueba cuando el percentil 75 de las visitas reales cae en el rango bueno en las tres métricas. Dicho de forma simple, al menos tres de cada cuatro visitas deben cumplir el umbral o mejorarlo.

De aquí se derivan dos consecuencias prácticas. Primera: una sola prueba rápida en tu portátil no demuestra nada, porque los visitantes usan otros dispositivos, redes y distancias al servidor. Segunda: lo que mueve el percentil 75 es mejorar la cola de visitas lentas, así que conviene mirar móviles y conexiones débiles, no solo tu propio equipo.

El TTFB (tiempo hasta el primer byte) y el FCP (primer contenido visible) no forman parte de los Core Web Vitals, pero ayudan a encontrar la causa de un LCP lento.

Una misma página puede mostrar resultados distintos en herramientas distintas, porque existen dos tipos de datos.

Los datos de campo se recogen de usuarios reales de Chrome. Alimentan el Chrome UX Report (CrUX), que muestra PageSpeed Insights, y el informe de Core Web Vitals de Google Search Console. Los datos de campo dan el veredicto final porque reflejan la experiencia real. La desventaja es que las páginas nuevas o con poco tráfico pueden no tener datos.

Los datos de laboratorio salen de una única carga simulada, por ejemplo en Lighthouse. Son repetibles, así que sirven para depurar: cambias el código y ves el efecto al instante. Pero una prueba de laboratorio no sabe cómo se comporta la gente real, por lo que el INP normalmente no se mide completo en el laboratorio.

Una regla que funciona:

1. Toma el veredicto de Core Web Vitals de los datos de campo.
2. Busca las causas con herramientas de laboratorio.
3. Tras una corrección, espera a que los datos de campo se actualicen. CrUX agrega un periodo de varias semanas, así que el resultado no aparece de inmediato.

Si no se muestran datos de campo, no es un error del sitio. Significa que hay pocas visitas para ofrecer estadísticas.

Empieza por averiguar cuál es el elemento LCP. PageSpeed Insights y el panel Performance de Chrome DevTools lo señalan. Lo más habitual es la imagen principal o un titular grande.

Después, revisa las causas habituales de un LCP lento:

• Una imagen pesada. Comprímela, sirve un formato moderno (WebP o AVIF) y ajústala al tamaño con el que se muestra. El atributo srcset permite que los móviles descarguen una versión más pequeña.
• Carga diferida de la imagen principal. loading="lazy" es para imágenes situadas debajo de la primera pantalla. No lo pongas en la imagen LCP, o el navegador empezará a descargarla más tarde.
• Scripts y estilos que bloquean el renderizado. Un CSS grande y scripts síncronos en el head retrasan el primer pintado. Saca lo no crítico y añade defer a los scripts.
• Respuesta lenta del servidor. Si el servidor tarda en generar el HTML, ninguna optimización de imágenes salvará la métrica. Revisa la caché, la compresión (gzip o Brotli) y, si hace falta, una CDN.

Este es un ejemplo en el que la imagen principal carga de inmediato y la segunda espera:

<img src="/images/hero.webp" width="1200" height="630" alt="Resumen del informe" fetchpriority="high">
<img src="/images/chart.webp" width="800" height="450" alt="Gráfico de puntuación" loading="lazy">

El atributo fetchpriority="high" indica al navegador que la imagen importa. No es magia, pero es una elección razonable para la imagen LCP.

El INP trata de la interactividad, así que casi siempre acaba en JavaScript. Cuando el hilo principal está ocupado con una tarea larga, el navegador no puede reaccionar a tiempo a un clic y el usuario ve un botón que parece congelado.

Por dónde empezar:

• Localiza las tareas largas. El panel Performance de Chrome DevTools las marca en rojo. Divide los cálculos grandes en partes más pequeñas para que el hilo principal pueda atender la entrada entre ellas.
• Revisa los scripts de terceros. Los chats, la analítica, las etiquetas publicitarias y las herramientas de pruebas A/B suelen consumir mucho hilo principal. Elimina lo que no aporta y carga el resto más tarde.
• Simplifica los manejadores de eventos. Un clic no debería ejecutar trabajo pesado de forma síncrona. Muestra primero una respuesta visual y aplaza el resto.
• Ten en cuenta el coste de la hidratación. En aplicaciones basadas en frameworks modernos, dar vida a la página puede llevar un tiempo notable. Menos JavaScript en la página significa una respuesta más rápida.

Un sitio con pocos scripts rara vez tiene problemas de INP. Una página llena de funciones interactivas suele descubrir que el INP es su métrica más débil. Hay más detalle en web.dev sobre INP.

Los desplazamientos del diseño casi siempre tienen causas sencillas y son fáciles de corregir si sabes dónde mirar.

• Imágenes y vídeos sin dimensiones. Define width y height o la propiedad CSS aspect-ratio para que el navegador reserve espacio antes de que llegue el archivo.
• Anuncios, banners y widgets incrustados. Dales de antemano un contenedor con una altura mínima fija.
• Fuentes. Cuando una fuente web sustituye a la de reserva, el texto puede cambiar de tamaño y empujar la página. Elige una fuente de reserva con métricas parecidas y una estrategia font-display razonable.
• Contenido insertado encima del existente. Los avisos de consentimiento, las barras promocionales y las sugerencias que aparecen sobre texto ya visible lo empujan hacia abajo. Añade esos elementos superpuestos al contenido, por ejemplo como barra fija, o reserva espacio para ellos.

Un ejemplo que reserva espacio para un bloque incrustado:

<div style="aspect-ratio: 16 / 9; min-height: 240px;">
  <iframe src="https://example.com/embed" width="640" height="360" title="Bloque incrustado"></iframe>
</div>

Tras el cambio, prueba con una red lenta y una pantalla estrecha. Ahí es donde más se notan los desplazamientos.

No necesitas una docena de servicios de pago. Con cuatro herramientas gratuitas basta para empezar.

1. PageSpeed Insights. Muestra los datos de campo de CrUX de la página (cuando hay suficientes) y un informe de laboratorio de Lighthouse con sugerencias. Un buen punto de partida.
2. El informe de Core Web Vitals en Google Search Console. Agrupa las URL de tu sitio por estado en móvil y escritorio y muestra dónde está el problema.
3. El panel Performance de Chrome DevTools. Lo mejor para depurar: se ven las tareas largas, el elemento LCP y los desplazamientos.
4. La biblioteca JavaScript web-vitals. Un pequeño código que recoge LCP, INP y CLS de tus visitantes reales. Útil cuando quieres estadísticas propias y no solo las de CrUX.

Un orden sensato: abre primero el informe de Search Console, localiza el grupo de URL con problemas, revisa una página típica del grupo en PageSpeed Insights y solo después entra en DevTools. Así corriges una plantilla y no una sola página, y una plantilla corregida mejora muchas URL a la vez.

Recuerda que los Core Web Vitals son solo una parte de la salud técnica. Para la lista más amplia de cosas que revisar, consulta la lista de comprobación de SEO técnico. Temas relacionados: cabeceras de seguridad y SEO y datos estructurados JSON-LD.

Seamos directos: el escáner de SEOAudit es pasivo y no mide los Core Web Vitals. No ejecuta la página en un navegador, no ejecuta JavaScript y no recoge datos de visitantes reales. En el informe, los datos de campo de Core Web Vitals aparecen marcados como no compatibles (no evaluados) y nunca se muestran como superados. Tampoco estima LCP, CLS ni FCP a partir del tiempo de respuesta del servidor, porque esa estimación sería inventada.

Lo que sí informa son señales indirectas que suelen acompañar a métricas deficientes:

• el tiempo de respuesta de la única petición principal (no es una medición de Core Web Vitals);
• el tamaño del documento HTML;
• imágenes sin ancho ni alto (un indicador de riesgo de desplazamiento, no un CLS medido);
• formatos de imagen antiguos y la ausencia de srcset;
• una primera imagen con carga diferida;
• scripts que bloquean el renderizado en el head y una gran cantidad de archivos CSS y JS;
• el número de hosts de terceros y la falta de preconnect;
• cómo se cargan las fuentes web, según lo declarado en el HTML;
• la compresión, HTTP/2 y las cabeceras de caché.

Tómalo como una lista de causas probables. Ejecuta el escáner gratuito, anota las pistas y confirma después el efecto en PageSpeed Insights y Search Console. Lo que incluyen las comprobaciones SEO se describe en la página de auditoría SEO. Las comprobaciones de seguridad que se hacen en la misma petición se explican en la página de comprobación de seguridad, y la preparación para la búsqueda con IA en la de visibilidad en IA.