Core Web Vitals: qué son y cómo mejorar LCP, INP y CLS

Las Core Web Vitals (métricas web principales) son tres métricas con las que Google mide la experiencia real de una página: Largest Contentful Paint (LCP) para la carga, Interaction to Next Paint (INP) para la capacidad de respuesta y Cumulative Layout Shift (CLS) para la estabilidad visual. Una página las supera cuando al menos el 75 % de las visitas reales obtiene "bueno" en las tres.

En esta guía verás qué mide cada métrica, de dónde salen los datos, por qué PageSpeed Insights y Search Console muchas veces no coinciden y qué cambios mejoran de verdad cada métrica. También respondemos con honestidad a la pregunta de siempre: ¿cuánto influyen las Core Web Vitals en el posicionamiento?

¿Qué son las Core Web Vitals?

Las Core Web Vitals forman parte de la iniciativa Web Vitals de Google. Se eligieron estas tres porque cubren tres aspectos distintos de la experiencia: lo rápido que aparece el contenido principal, lo rápido que reacciona la página cuando tocas o escribes y si el diseño se mueve mientras lees.

El conjunto ha cambiado una sola vez. En marzo de 2024, INP sustituyó a First Input Delay (FID). FID solo medía el retraso antes de procesar la primera interacción; INP analiza la latencia de las interacciones durante toda la visita e informa de una de las más lentas. Si un artículo o una herramienta todavía habla de FID, está desactualizado.

¿Cuáles son los umbrales de las Core Web Vitals?

Google publica tres rangos para cada métrica. El objetivo es "bueno" en todas, tanto en móvil como en escritorio.

¿Qué significa "percentil 75"?

Google evalúa cada métrica en el percentil 75 de las cargas de página, por separado para móvil y escritorio. En la práctica, si el 75 % de las visitas tiene un LCP de 2,5 segundos o menos, la página es "buena" en LCP. El 25 % restante puede ser más lento sin que la evaluación falle.

Esto tiene dos consecuencias. Primero, una prueba rápida con el wifi de la oficina demuestra poco: decide el cuarto más lento de tus usuarios, a menudo con móviles Android de gama media y datos móviles. Segundo, los promedios esconden problemas. Una página con un LCP medio de 1,8 segundos puede suspender si una parte importante de las visitas llega con conexiones lentas. Al fijar objetivos, pregúntate "¿es bueno en el p75 en móvil?" y no "¿carga rápido en mi portátil?".

Datos de campo vs. datos de laboratorio: ¿por qué no coinciden?

Es la fuente de confusión más habitual, así que conviene ser precisos.

Los datos de campo (field data o RUM) proceden de usuarios reales de Chrome. La fuente pública de Google es el Chrome UX Report (CrUX), que agrega los últimos 28 días. Son los datos que Google usa para evaluar las Core Web Vitals y los que muestra Search Console.

Los datos de laboratorio proceden de una única carga simulada, normalmente con Lighthouse, con un dispositivo y una red fijos. Son reproducibles y muy útiles para depurar, pero no son lo que Google evalúa.

La regla práctica: usa los datos de campo para decidir qué corregir y confirmar que está resuelto; usa el laboratorio para entender el porqué y validar un cambio antes de publicarlo. Un 95 en Lighthouse con datos de campo en rojo significa que tus usuarios reales tienen peor experiencia que la simulación, no que Google se equivoque.

¿Cómo medir las Core Web Vitals y la velocidad de carga de tu web?

Varias herramientas gratuitas cubren todo el proceso, desde la vista general del sitio hasta una sola interacción lenta.

• Google Search Console → informe "Métricas web principales". Agrupa URLs similares y muestra cuántas son buenas, necesitan mejorar o son deficientes, en móvil y escritorio. Empieza por aquí. Se basa en datos de CrUX, así que los sitios con poco tráfico pueden ver "no hay suficientes datos".
• PageSpeed Insights (pagespeed.web.dev). Arriba muestra los datos de campo de CrUX para la URL (o para todo el origen si la URL tiene poco tráfico); abajo, una ejecución de Lighthouse con diagnósticos.
• API de CrUX, CrUX Vis y BigQuery. Para tendencias históricas y comparar con la competencia.
• Chrome DevTools → panel Performance. Muestra LCP, INP y CLS en vivo mientras interactúas y permite grabar una traza para ver qué script bloquea una interacción.
• La librería JavaScript web-vitals. Envía las métricas de tus visitantes a tu analítica, con datos de atribución (qué elemento fue el LCP, qué interacción fue lenta). Así obtienes datos de campo incluso de páginas que CrUX no cubre.

Un flujo que funciona: abre el informe de Search Console, elige el peor grupo de URLs en móvil, analiza una URL representativa en PageSpeed Insights, reproduce el problema en DevTools y corrígelo.

¿Qué causa un LCP lento y cómo se soluciona?

El elemento LCP suele ser una imagen (un banner principal, la foto de un producto) o un bloque de texto grande. Google divide el LCP en cuatro partes: tiempo hasta el primer byte (TTFB), retraso en la carga del recurso, duración de la carga del recurso y retraso en el renderizado del elemento. Averigua cuál pesa más antes de tocar nada.

Soluciones habituales:

• Haz que la imagen LCP se descubra pronto. Debe estar en el HTML inicial como <img> con src, no insertada con JavaScript ni como fondo CSS.
• Nunca apliques lazy loading a la imagen LCP y dale prioridad alta:

<img src="/images/hero-1200.avif"
     srcset="/images/hero-800.avif 800w, /images/hero-1200.avif 1200w"
     sizes="100vw" width="1200" height="600"
     alt="Panel de un informe de auditoría SEO"
     fetchpriority="high">

• Reduce el TTFB con caché, CDN y renderizado en servidor o generación estática, en lugar de construir el contenido principal en el navegador.
• Sirve imágenes más ligeras: formatos modernos (AVIF, WebP), tamaños correctos con srcset y compresión.
• Elimina recursos que bloquean el renderizado: CSS crítico en línea, JavaScript no crítico diferido y sin cadenas de redirecciones antes de cargar la página.

¿Qué causa un INP alto y cómo se soluciona?

INP mide el ciclo completo de una interacción: el retraso de entrada (el hilo principal está ocupado), el tiempo de procesamiento (tus manejadores de eventos) y el retraso de presentación (pintar el siguiente fotograma). Casi todos los problemas de INP se reducen a demasiado JavaScript ejecutándose en el hilo principal en el peor momento.

Soluciones habituales:

• Divide las tareas largas (todo lo que supere los 50 ms). Cede el control al navegador entre bloques de trabajo para que pueda responder al usuario:

button.addEventListener('click', async () => {
  showSpinner();              // primero, feedback visual
  await scheduler.yield();    // deja que el navegador pinte (alternativa: setTimeout)
  runExpensiveFilter();
});

• Revisa los scripts de terceros: chats, gestores de etiquetas, pruebas A/B y publicidad son culpables frecuentes. Quita lo que no uses y carga el resto más tarde.
• Haz menos trabajo por interacción: aplica debounce a los manejadores de entrada, evita volver a renderizar toda la página por un cambio pequeño y mantén un DOM de tamaño razonable.
• Evita el layout thrashing: leer propiedades de diseño (como offsetHeight) justo después de cambiar estilos obliga a recalcular el diseño de forma síncrona.

Como las herramientas de laboratorio no hacen clic por ti, confirma los problemas de INP con datos de campo o interactuando con la página en DevTools.

¿Qué causa un CLS alto y cómo se soluciona?

El CLS aumenta cada vez que el contenido visible se mueve sin que el usuario lo provoque: una imagen carga sin espacio reservado, un banner de cookies empuja la página hacia abajo o una fuente web se intercambia con otras métricas.

Soluciones habituales:

• Define siempre width y height (o aspect-ratio en CSS) en imágenes, vídeos e iframes para que el navegador reserve el espacio.
• Reserva espacio para anuncios, embeds y widgets que cargan tarde con un contenedor de altura mínima fija.
• No insertes contenido encima del existente salvo como respuesta a una acción del usuario. Muestra los banners superpuestos, no desplazando el diseño.
• Estabiliza las fuentes: precarga las principales y usa font-display con una fuente alternativa ajustada (size-adjust) para reducir el salto.
• Anima con transform, no con propiedades como top o height, que provocan desplazamientos.
• Mantén las páginas compatibles con la caché de páginas completas (bfcache), para que volver atrás sea instantáneo y estable.

Soluciones para las Core Web Vitals de un vistazo

¿Cuánto influyen las Core Web Vitals en el SEO?

Las Core Web Vitals forman parte de las señales que usan los sistemas de clasificación de Google, dentro del concepto de experiencia en la página (page experience). Pero Google Search Central deja claro que la relevancia va primero: una página con métricas excelentes no superará a otra mucho más relevante y útil. Unas buenas puntuaciones, por sí solas, no garantizan las primeras posiciones.

En la práctica funcionan como un criterio de desempate. Cuando varias páginas son igual de relevantes y fiables, una mejor experiencia puede ayudar. Pasar de "deficiente" a "bueno" merece la pena; perseguir un 100 perfecto en Lighthouse en páginas que ya aprueban rara vez cambia el posicionamiento.

El argumento de más peso es el de negocio. Las páginas lentas, que saltan o tardan en responder pierden visitas y conversiones, independientemente del ranking. Por eso las Core Web Vitals aparecen en toda auditoría SEO técnica seria: no como la palanca principal de posicionamiento, sino como una parte medible de la experiencia que ven usuarios y buscadores.

¿Afectan las Core Web Vitals a AI Overviews?

Google no ha descrito las Core Web Vitals como un factor específico para sus funciones de IA. AI Overviews y AI Mode se basan en páginas indexadas y aptas para aparecer en la Búsqueda, así que aplican los mismos fundamentos: páginas rastreables, indexables y útiles. Una página rápida es, sencillamente, un motivo menos para que el usuario se vaya.

Cómo priorizar el trabajo en Core Web Vitals

1. Mira primero los datos de campo. Si Search Console y PageSpeed Insights muestran "bueno" en móvil, probablemente el rendimiento no sea tu mayor problema SEO.
2. Corrige plantillas, no URLs sueltas. Search Console agrupa páginas similares: un cambio en la plantilla de producto o de artículo puede mejorar miles de URLs.
3. Empieza por lo "deficiente", en móvil y en las plantillas con más tráfico. Ahí están los usuarios y los ingresos.
4. Valida y espera. Tras publicar, usa "Validar corrección" en Search Console y cuenta con hasta 28 días para que CrUX refleje el cambio.
5. Monitoriza con RUM para detectar regresiones (un script nuevo, un rediseño) en días, no en meses.

Para ver cómo encajan las Core Web Vitals con la revisión de indexación, contenido y enlazado interno, consulta nuestro checklist de auditoría SEO.

Puntos clave

• Las Core Web Vitals son LCP (≤ 2,5 s), INP (≤ 200 ms) y CLS (≤ 0,1), evaluadas en el percentil 75 de datos de usuarios reales.
• INP sustituyó a FID en marzo de 2024; las herramientas de laboratorio lo aproximan con Total Blocking Time.
• Google evalúa los datos de campo (CrUX), no tu puntuación de Lighthouse. El laboratorio sirve para depurar.
• Corrige por plantilla y por métrica: prioriza la imagen LCP, reduce el JavaScript del hilo principal y reserva espacio para todo lo que carga tarde.
• Las Core Web Vitals son una señal de posicionamiento real pero moderada; la relevancia y la calidad del contenido pesan más.

Revisa las Core Web Vitals de tu web en contexto

Las métricas de velocidad son más útiles junto a todo lo demás que afecta a tu visibilidad: indexación, canonical, contenido y enlaces internos. Si quieres una visión basada en evidencias de dónde está tu sitio, puedes solicitar una vista previa gratuita de la auditoría SEO con tu puntuación y varios problemas reales, o ver antes el informe de ejemplo.