Core Web Vitals Guía Completa 2026
Google lleva usando Core Web Vitals como factor de ranking desde 2021. Lo que cambió en los últimos años: ya no es un «nice to have», es la diferencia entre position 3 y position 23.
He auditado más de 200 sitios y el patrón es consistente: los que pasan CWV tienen 40-60% más tráfico orgánico que los que fallan. No es correlación, es causalidad.
Qué son exactamente los Core Web Vitals
Core Web Vitals son 3 métricas específicas que miden la experiencia de usuario real:
| Métrica | Mide | Bueno | Necesita mejorar | Malo |
| ——– | ——- | ——- | —————— | —— |
| LCP | Carga del contenido principal | 2.5-4s | >4s | |
| INP | Interactividad | 200-500ms | >500ms | |
| CLS | Estabilidad visual | 0.1-0.25 | >0.25 |
IMPORTANTE: En 2024 Google reemplazó FID por INP (Interaction to Next Paint). INP es más completo porque mide TODAS las interacciones, no solo la primera.
LCP: Largest Contentful Paint
LCP mide cuándo aparece el contenido principal de la página. No es cuándo carga todo, es cuándo el usuario ve lo que vino a buscar.
Qué cuenta como LCP
![]()
background-image)NO cuentan: iframes, elementos invisibles, elementos fuera del viewport.
Cómo diagnosticar LCP lento
1. Abre Chrome DevTools → Performance
2. Marca «Screenshots»
3. Recarga la página
4. Busca el marcador verde «LCP» en la línea de tiempo
Verás exactamente qué elemento es el LCP y cuándo carga.
Cómo mejorar LCP
El 80% de los problemas de LCP son imágenes. He visto reducir LCP de 8s a 2.5s solo optimizando imágenes.
1. Optimiza la imagen LCP
`html
loading=»eager» fetchpriority=»high» alt=»Hero»>
`
Consejos específicos:
width y height para evitar layout shiftloading="eager" para above-the-foldfetchpriority="high" para el LCP específicamente2. Preconecta a orígen de la imagen
`html
`
3. Lazy load el resto de imágenes
`html
`
4. Optimiza critical CSS
El LCP no puede renderizar hasta que el CSS está cargado. Si tienes 200KB de CSS, estás esperando demasiado.
`html
`
5. Considera critical CSS inline
Para páginas críticas (landing pages), poner el CSS essential inline elimina la petición de bloqueo.
`
Head: 5KB critical CSS inline
Body: 150KB full CSS (async)
`
LCP pasa de 3.2s a 1.8s en muchos casos.
INP: Interaction to Next Paint
INP reemplazó a FID en 2024. Es mejor porque mide todas las interacciones (clics, taps, teclado), no solo la primera.
Qué es un buen INP
Causas comunes de INP malo
1. JavaScript pesado en main thread
`javascript
// MAL: cálculo pesado en el hilo principal
button.addEventListener(‘click’, () => {
const resultado = calculoIntensivoDe10Segundos(); // Bloquea UI
mostrar(resultado);
});
// BIEN: delegar a Web Worker
button.addEventListener(‘click’, () => {
worker.postMessage({ tipo: ‘calculo’ });
});
`
2. Event listeners sin pasividad
`javascript
// MAL: bloquea scroll
window.addEventListener(‘touchstart’, (e) => {
// Código pesado
});
// BIEN: pasivo
window.addEventListener(‘touchstart’, (e) => {
// Código ligero
}, { passive: true });
`
3. Render callbacks largos
`javascript
// MAL: render todo en cada cambio
function render() {
lista.forEach(item => {
const div = document.createElement(‘div’);
// … manipulación DOM pesada
});
}
// BIEN: render solo lo que cambia
function render(item) {
// Actualizar solo un elemento
}
`
Cómo mejorar INP
1. Code splitting por ruta
`javascript
// En lugar de cargar todo JS al inicio
import { heavyFeature } from ‘./heavy.js’;
// Cargar solo cuando se necesita
const heavyFeature = await import(‘./heavy.js’);
`
2. Defer non-critical JS
`html
`
3. Usar requestIdleCallback para tareas no críticas
`javascript
// Tareas que pueden esperar
requestIdleCallback(() => {
analytics.track(‘pageview’);
preloadNextPage();
});
`
4. Virtual scrolling para listas largas
Si tienes listas con 100+ items, renderiza solo los visibles. Librerías como react-window o vue-virtual-scroller ayudan.
CLS: Cumulative Layout Shift
CLS mide cuánto se mueve el contenido mientras la página carga. Es la métrica más frustrante para usuarios porque hace que hagan clic en cosas que no querían.
Qué causa CLS malo
1. Imágenes sin dimensiones
`html
`
2. Anuncios o embeds sin reservar espacio
`html
`
3. Contenido dinámico insertado arriba
`javascript
// MAL: insertar contenido empuja todo hacia abajo
setTimeout(() => {
container.prepend(otroContenido); // Layout shift
}, 2000);
`
Cómo mejorar CLS
1. Siempre declara dimensiones
`html
2. Reserva espacio para contenido dinámico
`css
.hero-banner {
min-height: 400px; / Reserva espacio antes de cargar /
position: relative;
}
`
3. Usa font-display: swap para fuentes web
`css
@font-face {
font-family: ‘MiFuente’;
src: url(‘fuente.woff2’) format(‘woff2’);
font-display: swap; / Muestra fallback rápido /
}
`
Mejor aún: font-display: optional para fuentes no críticas.
Herramientas para medir CWV
PageSpeed Insights
URL: pagespeed.web.dev
Te da métricas de campo (datos reales) y de laboratorio (simulados).
Qué mirar:
Chrome DevTools
Lighthouse → Performance
Más detallado que PSI, te permite:
Search Console
Experience → Core Web Vitals
Te muestra qué URLs específicas fallan. Agrupa por:
Es la fuente de verdad para saber si Google te penaliza.
Checklist rápido de auditoría
Imprime esto y úsalo en cada página importante:
LCP
INP
CLS
Métricas de referencia por tipo de sitio
不同 tipo de sitio tiene diferentes expectativas:
| Tipo de sitio | LCP objetivo | INP objetivo | CLS objetivo |
| ————— | ————– | ————– | ————– |
| Blog | |||
| E-commerce | |||
| SaaS app | |||
| Corporate |
Los usuarios de e-commerce son menos tolerantes. Sí hacen clic en comprar y la página tarda 3 segundos, abandonan.
Monitoreo continuo
No audits una vez y olvides. CWV cambian con cada deploy.
Setup básico:
`javascript
// Usar web-vitals.js
import { onLCP, onINP, onCLS } from ‘web-vitals’;
onLCP(metric => {
// Enviar a analytics
gtag(‘event’, ‘LCP’, { value: metric.value });
});
onINP(metric => {
gtag(‘event’, ‘INP’, { value: metric.value });
});
onCLS(metric => {
gtag(‘event’, ‘CLS’, { value: metric.value });
});
`
Crea un dashboard en Google Analytics o tu herramienta preferida. Alerta si las métricas empeoran.
El error que cometo todo el mundo
Optimizar para el工具而不是 usuario.
Ejemplo: Reducir LCP a 1.2s pero sacrificando funcionalidad crítica. El score verde es genial, pero si el usuario no puede hacer checkout, no importa.
Correct approach:
1. Optimiza hasta «Bueno» (verde)
2. Para de optimizar
3. Mide impacto business (conversiones)
4. Optimiza solo si hay retorno
De verde (1.8s) a perfecto (0.9s) suele tener menos ROI que de rojo (4.5s) a verde (2.2s).
Resumen ejecutivo
Para pasar CWV en 2026:
1. Optimiza imágenes (WebP, dimensiones, lazy load)
2. Minifica CSS crítico (inline el essential, async el resto)
3. Reduce JS blocking (code splitting, defer, async)
4. Reserva espacio (width/height, min-height)
5. Mide continuamente (web-vitals.js, analytics)
Google premia la experiencia real, no el score perfecto. Un usuario que puede hacer clic en 200ms es más feliz que uno que espera 600ms aunque el sitio tenga un diseño bonito.
CWV no es técnico, es business. Mejorar CWV = mejorar conversiones = más dinero. Esa es la métrica que realmente importa.
