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.
Qué son los Core Web Vitals
LCP — bueno
Elemento más grande renderizado
INP — bueno
La interfaz responde a la entrada del usuario
CLS — bueno
Desplazamiento mínimo del diseño
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.
Google presenta tres métricas: LCP, FID y CLS. Las herramientas empiezan a soportar las nuevas señales.
Los CWV entran oficialmente en el algoritmo de posicionamiento. El despliegue termina en agosto de 2021.
Interaction to Next Paint sustituye a First Input Delay. INP abarca todas las interacciones de la sesión, no solo la primera.
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 LCP | Valoración | Acción |
|---|---|---|
| ≤ 2,5 s | Bueno | Mantener y vigilar en GSC |
| 2,5 – 4,0 s | Necesita mejorar | Optimizar imágenes, reducir el TTFB |
| > 4,0 s | Malo | Prioridad 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)
<!-- 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"
/>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.
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()nisetTimeout(0)para trocear las tareas largas - Los scripts de terceros (chat, publicidad, analítica) ocupan el hilo principal
- Animaciones con JS en lugar de
transformuopacityde CSS
// 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 CLS | Valoración | Causa típica |
|---|---|---|
| ≤ 0,1 | Bueno | Espacio reservado para todos los elementos |
| 0,1 – 0,25 | Necesita mejorar | Fuentes sin font-display: swap, banners |
| > 0,25 | Malo | Imágenes sin dimensiones, inserciones dinámicas |
Fuentes habituales de CLS
- Imágenes sin los atributos
widthyheight: el navegador no conoce su tamaño antes de cargarlas - Fuentes web sin
font-display: optionalniswap: 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,leftomarginen lugar detransform - Anuncios sin espacio reservado (
min-heighten el contenedor)
/* 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 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.
| Tipo | Herramienta | Qué muestra | Caso de uso |
|---|---|---|---|
| Campo | Google Search Console | CWV de todas las URL del sitio (p75) | Priorizar páginas problemáticas |
| Campo | Panel de CrUX (Looker) | Tendencias con ventana de 28 días | Seguir el progreso en el tiempo |
| Laboratorio | PageSpeed Insights | LCP/INP/CLS + recomendaciones | Diagnosticar una URL concreta |
| Laboratorio | Lighthouse (DevTools) | Cascada detallada, traza | Análisis profundo de la causa raíz |
| Laboratorio | WebPageTest | Grabación en vídeo, filmstrip | Comparación antes y después |
Herramientas de diagnóstico
| Herramienta | Gratuita | LCP | INP |
|---|---|---|---|
| Google Search Console | Sí | ✓ | ✓ |
| PageSpeed Insights | Sí | ✓ | ✓ |
| Chrome DevTools | Sí | ✓ | ✓ |
| Lighthouse CI | Sí | ✓ | ✓ |
| WebPageTest | Sí (con límites) | ✓ | ✓ |
| SpeedCurve | De pago | ✓ | ✓ |
| Sentry (SDK web-vitals) | Freemium | ✓ | ✓ |
| Herramienta | CLS | Datos de campo |
|---|---|---|
| Google Search Console | ✓ | ✓ |
| PageSpeed Insights | ✓ | ✓ (CrUX) |
| Chrome DevTools | ✓ | — |
| Lighthouse CI | ✓ | — |
| WebPageTest | ✓ | — |
| SpeedCurve | ✓ | ✓ |
| Sentry (SDK web-vitals) | ✓ | ✓ |
// 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
LCP
- Añade
fetchpriority="high"y quitaloading="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=31536000para 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()osetTimeout(0) - Aplica debounce a los manejadores de
inputyscroll(16–100 ms) - Optimiza React:
useMemo,useCallback,React.memoy virtualización de listas - Mueve los scripts de terceros a Web Workers o cárgalos después del LCP
- Anima solo con
transformyopacityen CSS
CLS
- Define
widthyheighten todos los elementos<img>: el navegador reserva el espacio - Usa
aspect-ratioen los contenedores de dimensiones desconocidas - Configura
font-display: optionalpara las fuentes críticas - Reserva
min-heightpara 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
¿Qué son los Core Web Vitals y por qué importan para el SEO?
¿Cómo compruebo los Core Web Vitals de mi sitio?
El LCP supera los 4 segundos: ¿cuánto de urgente es corregirlo?
¿Los umbrales de Core Web Vitals son iguales en móvil y en escritorio?
¿Qué pesa más en e-commerce: el LCP o el CLS?
Check it with SpiderHead
Free and local: run the audit on your own machine.



