Core Web Vitals: guía completa 2026

Cómo interpretar LCP, INP y CLS con datos de campo, diagnosticar la capa responsable y mejorar la experiencia de usuario sin prometer posiciones en los resultados.

Los Core Web Vitals (CWV) son el conjunto de métricas de Google que miden la experiencia real del usuario: velocidad de carga, capacidad de respuesta de la interfaz y estabilidad visual. Desde mayo de 2021 forman parte de Page Experience e influyen en el posicionamiento.

Las tres métricas se evalúan por URL: las buenas puntuaciones de la portada no sirven de nada en las fichas de producto. Google toma los datos del Chrome UX Report (usuarios reales), no de simulaciones de laboratorio.

Las tres métricas de Core Web Vitals y sus umbrales en verde. Una página se considera buena cuando el 75 % de los usuarios reales cae en la zona verde.
Google evalúa los CWV con el umbral p75, es decir, el percentil 75. Una página es «buena» cuando el 75 % de los usuarios reales experimenta la métrica en la zona verde. Las herramientas de laboratorio, como Lighthouse, muestran un dispositivo mediano: sirven para diagnosticar, no como evaluación final.

Qué son los Core Web Vitals

≤ 2,5 s

LCP — bueno

Elemento más grande renderizado

≤ 200 ms

INP — bueno

La interfaz responde a la entrada del usuario

≤ 0,1

CLS — bueno

Desplazamiento mínimo del diseño

75 %

Umbral de evaluación

Proporción de usuarios en la zona verde

Historia: de FID a INP

Google presentó los Core Web Vitals en 2020 con tres métricas: LCP, FID (First Input Delay) y CLS. FID medía el retraso del primer toque: un dato valioso, pero que solo cubría una parte de la interactividad de la página.

mayo de 2020Anuncio de los Core Web Vitals

Google presenta tres métricas: LCP, FID y CLS. Las herramientas empiezan a soportar las nuevas señales.

junio de 2021Actualización Page Experience

Los CWV entran oficialmente en el algoritmo de posicionamiento. El despliegue termina en agosto de 2021.

marzo de 2024FID → INP

Interaction to Next Paint sustituye a First Input Delay. INP abarca todas las interacciones de la sesión, no solo la primera.

2025–2026INP en la práctica

Los sitios con mucho JavaScript (SPA, e-commerce, filtros) notan la presión de INP. Optimizar las Long Tasks se convierte en prioridad.

LCP — Largest Contentful Paint

LCP registra el momento en que el bloque de contenido visible más grande de la página queda pintado por completo. Normalmente es una imagen principal (hero), la portada de un artículo o un H1 de gran tamaño.

Valor de LCPValoraciónAcción
≤ 2,5 sBuenoMantener y vigilar en GSC
2,5 – 4,0 sNecesita mejorarOptimizar imágenes, reducir el TTFB
> 4,0 sMaloPrioridad máxima, auditar de inmediato

Causas habituales de un LCP lento

  • TTFB lento (servidor, CDN, falta de caché): supone hasta el 40 % del tiempo de LCP
  • La imagen principal no está priorizada: falta fetchpriority="high"
  • La imagen principal no está precargada (<link rel="preload">)
  • El CSS y el JS que bloquean el renderizado retrasan el primer pintado
  • Imágenes demasiado grandes: sin WebP ni AVIF, sin srcset
  • El elemento LCP depende de un renderizado con JS (el SSR de React no ha terminado cuando se produce el LCP)
Ejemplo de priorización del recurso LCP:
html
<!-- Prioritise the LCP image -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

<img
  src="/hero.webp"
  alt="Hero"
  fetchpriority="high"
  loading="eager"
  decoding="async"
  width="1280"
  height="720"
/>
No uses loading="lazy" en la imagen principal: el navegador retrasará su carga y el LCP aumentará. Usa lazy solo en las imágenes que quedan por debajo del pliegue.

INP — Interaction to Next Paint

INP mide el retraso entre cualquier interacción del usuario (clic, pulsación de tecla, toque) y el siguiente pintado visual de la página. A diferencia de FID, INP tiene en cuenta todas las interacciones de la sesión y toma el peor caso, descartando los valores atípicos.

Anatomía de INP

INP = retraso de entrada + tiempo de procesamiento + retraso de presentación

Retraso de entrada (espera en cola)hasta 50 ms
Tiempo de procesamiento (manejador de JS)hasta 100 ms
Retraso de presentación (renderizado y pintado)hasta 50 ms

Qué rompe INP

  • Las Long Tasks de más de 50 ms bloquean el hilo principal: el navegador no puede procesar la entrada
  • Manejadores de eventos pesados: setState síncrono en React, actualizaciones masivas del DOM
  • No se usa scheduler.yield() ni setTimeout(0) para trocear las tareas largas
  • Los scripts de terceros (chat, publicidad, analítica) ocupan el hilo principal
  • Animaciones con JS en lugar de transform u opacity de CSS
Ejemplo de división de una Long Task con el planificador:
javascript
// Breaking up a Long Task with scheduler.yield()
async function processLargeList(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    // Yield to the main thread every 50 items
    if (i % 50 === 0) {
      await scheduler.yield();
    }
  }
}
scheduler.yield() es una alternativa moderna a setTimeout(0). El navegador devuelve el control, procesa la entrada del usuario y después retoma la tarea. Es compatible con Chrome 115 y versiones posteriores; para el resto de navegadores, usa un polyfill con setTimeout.

CLS — Cumulative Layout Shift

CLS es una métrica sin unidades que describe el desplazamiento total e inesperado de los elementos de la página. Fórmula: fracción de impacto × fracción de distancia. No cuenta el desplazamiento de un botón que el usuario acaba de pulsar: solo los elementos que se mueven sin acción del usuario.

Valor de CLSValoraciónCausa típica
≤ 0,1BuenoEspacio reservado para todos los elementos
0,1 – 0,25Necesita mejorarFuentes sin font-display: swap, banners
> 0,25MaloImágenes sin dimensiones, inserciones dinámicas

Fuentes habituales de CLS

  • Imágenes sin los atributos width y height: el navegador no conoce su tamaño antes de cargarlas
  • Fuentes web sin font-display: optional ni swap: el FOUT desplaza el texto
  • Banners o avisos de cookies insertados dinámicamente en la parte superior de la página
  • Animaciones CSS que cambian top, left o margin en lugar de transform
  • Anuncios sin espacio reservado (min-height en el contenedor)
Ejemplo de reserva de espacio para evitar CLS:
css
/* Reserve space for an ad slot */
.ad-container {
  min-height: 250px;
  width: 100%;
}

/* Animation without CLS: transform and opacity only */
.card:hover {
  transform: translateY(-4px);
  /* Wrong: margin-top: -4px — this shifts layout */
}

Impacto en el posicionamiento

Google confirmó que los CWV son una de las señales de Page Experience que participan en el posicionamiento. Pero actúan como desempate, no como factor principal. Una página con contenido excelente y mal CWV superará a una página con buen CWV y contenido flojo.

El efecto real de los CWV: los sitios en la zona verde tienen tasas de rebote más bajas y aparecen en el informe Page Experience de Google Search Console. Prueba rápida: si un competidor con contenido similar te supera, revisa sus CWV en PageSpeed Insights.

El efecto indirecto pesa más: las páginas rápidas reducen el abandono y aumentan la profundidad de sesión y la conversión. El argumento de negocio para los CWV es más sólido que el argumento de SEO. Amazon calculó que +100 ms de LCP equivalen a −1 % de ingresos.

Cómo medir los CWV

Hay dos tipos de datos: datos de laboratorio (simulación, con Lighthouse o WebPageTest) y datos de campo (usuarios reales, con CrUX o GSC). Google usa los datos de campo para el posicionamiento. El laboratorio sirve para diagnosticar.

TipoHerramientaQué muestraCaso de uso
CampoGoogle Search ConsoleCWV de todas las URL del sitio (p75)Priorizar páginas problemáticas
CampoPanel de CrUX (Looker)Tendencias con ventana de 28 díasSeguir el progreso en el tiempo
LaboratorioPageSpeed InsightsLCP/INP/CLS + recomendacionesDiagnosticar una URL concreta
LaboratorioLighthouse (DevTools)Cascada detallada, trazaAnálisis profundo de la causa raíz
LaboratorioWebPageTestGrabación en vídeo, filmstripComparación antes y después
PageSpeed Insights muestra los dos tipos de datos en una sola página: arriba, los datos de campo (CrUX); abajo, los de laboratorio (Lighthouse). Usa los datos de campo para valorar el estado y los de laboratorio para encontrar las causas.

Herramientas de diagnóstico

HerramientaGratuitaLCPINP
Google Search ConsoleSí✓✓
PageSpeed InsightsSí✓✓
Chrome DevToolsSí✓✓
Lighthouse CISí✓✓
WebPageTestSí (con límites)✓✓
SpeedCurveDe pago✓✓
Sentry (SDK web-vitals)Freemium✓✓
CLS y datos de campo para las mismas herramientas:
HerramientaCLSDatos de campo
Google Search Console✓✓
PageSpeed Insights✓✓ (CrUX)
Chrome DevTools✓—
Lighthouse CI✓—
WebPageTest✓—
SpeedCurve✓✓
Sentry (SDK web-vitals)✓✓
Para la monitorización en producción, añade la librería JS web-vitals de Google: recoge los CWV reales y los envía a tu analítica (GA4, Sentry, DataDog).
javascript
// web-vitals v4 — collect real CWV
import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics({ name, value, id }) {
  // Send to GA4
  gtag('event', name, {
    value: Math.round(name === 'CLS' ? value * 1000 : value),
    metric_id: id,
    metric_delta: value,
  });
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Lista de comprobación de optimización

Valores umbral de Core Web Vitals de Google para LCP, INP y CLS.

LCP

  • Añade fetchpriority="high" y quita loading="lazy" de la imagen principal
  • Añade <link rel="preload" as="image"> para la imagen principal en el <head>
  • Convierte las imágenes a WebP o AVIF y configura srcset
  • Reduce el TTFB a ≤ 800 ms: CDN, caché, SSR en el edge
  • Elimina los scripts que bloquean el renderizado del <head> (async, defer, module)
  • Configura Cache-Control: max-age=31536000 para los recursos estáticos

INP

  • Perfila las Long Tasks en Chrome DevTools → Performance → Main Thread
  • Divide las tareas de más de 50 ms con scheduler.yield() o setTimeout(0)
  • Aplica debounce a los manejadores de input y scroll (16–100 ms)
  • Optimiza React: useMemo, useCallback, React.memo y virtualización de listas
  • Mueve los scripts de terceros a Web Workers o cárgalos después del LCP
  • Anima solo con transform y opacity en CSS

CLS

  • Define width y height en todos los elementos <img>: el navegador reserva el espacio
  • Usa aspect-ratio en los contenedores de dimensiones desconocidas
  • Configura font-display: optional para las fuentes críticas
  • Reserva min-height para los espacios de anuncios y el contenido dinámico
  • Coloca los avisos (cookies, banners) abajo, no arriba de la página
  • Revisa el FOUT: las fuentes sin fallback desplazan el texto al cargarse
Prioridad: empieza por el LCP, que suele estar en rojo y tiene el mayor peso en Page Experience. Cuando el LCP esté en verde, pasa al INP (crítico en SPA y páginas interactivas) y, después, al CLS.
¿Qué son los Core Web Vitals y por qué importan para el SEO?
Los Core Web Vitals miden la velocidad de carga, la interactividad y la estabilidad visual. Google indica que los sistemas de posicionamiento los usan como parte de una experiencia de página más amplia, pero una buena puntuación no garantiza las primeras posiciones: la relevancia y otras señales siguen importando.
¿Cómo compruebo los Core Web Vitals de mi sitio?
Usa el informe de Core Web Vitals de Google Search Console, PageSpeed Insights (datos reales de CrUX y datos de laboratorio), la pestaña Performance de Chrome DevTools o Lighthouse. Para una monitorización continua, integra la librería web-vitals.js y envía los datos a GA4.
El LCP supera los 4 segundos: ¿cuánto de urgente es corregirlo?
Trátalo como prioridad de experiencia de usuario y de diagnóstico. Localiza el elemento LCP, su ruta de entrega y el grupo de dispositivos afectado, y después verifica el cambio tanto en los datos de laboratorio como en los de campo. No prometas un resultado de posicionamiento ni unos plazos a partir de una sola corrección.
¿Los umbrales de Core Web Vitals son iguales en móvil y en escritorio?
Los umbrales son los mismos (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1), pero las puntuaciones se miden por separado. El móvil suele rendir peor por procesadores y redes más lentos. GSC muestra los dos segmentos: prioriza el móvil.
¿Qué pesa más en e-commerce: el LCP o el CLS?
El LCP es más crítico para la conversión: un elemento principal lento en una página de producto o de aterrizaje reduce directamente las ventas (según datos de Google, aproximadamente −1 % de conversión por cada +0,1 s de LCP). El CLS es más crítico para la UX: un botón de compra que se desplaza bajo el cursor es una fuente directa de abandonos. Trabaja en ambos a la vez.

Check it with SpiderHead

Free and local: run the audit on your own machine.

Try it