Intermedio15 minutos de lectura•6 de febrero de 2026

#Core Web Vitals#INP#LCP#CLS#velocidad sitio web#SEO técnico#PageSpeed

Por

Core Web Vitals en 2026: Guía Completa de INP, LCP y CLS

En mayo de 2021, Google hizo oficial lo que muchos sospechábamos: la experiencia de usuario (medida técnicamente) es un factor de ranking. Los Core Web Vitals se convirtieron en parte del algoritmo.

Pero aquí está el problema: en marzo de 2024, Google reemplazó una de las tres métricas principales (FID por INP), y muchos sitios aún no se han adaptado. Si tu sitio web todavía está optimizado para FID, estás perdiendo rankings.

En esta guía te voy a explicar exactamente qué son los Core Web Vitals en 2026, cómo medir cada métrica correctamente, y las técnicas específicas para optimizar INP, LCP y CLS.

¿Qué Son los Core Web Vitals?

Los Core Web Vitals son un conjunto de métricas específicas que Google usa para medir la experiencia real de los usuarios en tu sitio web.

Las 3 métricas principales en 2026:

INP (Interaction to Next Paint) - Mide interactividad [NUEVO desde marzo 2024]
LCP (Largest Contentful Paint) - Mide velocidad de carga
CLS (Cumulative Layout Shift) - Mide estabilidad visual

💡 Cambio importante: Hasta marzo 2024, la métrica de interactividad era FID (First Input Delay). INP es más comprehensivo y refleja mejor la experiencia real.

¿Por Qué Importan Para SEO?

Razón #1: Factor de Ranking Confirmado

Google oficialmente incluye Core Web Vitals en el "Page Experience" signal. Aunque no es el factor más importante (contenido sigue siendo #1), sí afecta rankings.

Impacto real:

Estudio de Ahrefs (2024):
- Sitios con "Good" CWV: +8.3% tráfico promedio
- Sitios con "Poor" CWV: -12.1% tráfico promedio

Razón #2: Afectan Conversión

Velocidad y UX impactan directamente conversiones:

100ms de retraso: -1% conversión (Amazon study)
1 segundo de carga adicional: -7% conversión promedio
Layouts inestables (CLS alto): -25% en clicks en elementos afectados

Razón #3: Mobile-First Indexing

Google usa la versión móvil de tu sitio para ranking. Mobile tiene:

Conexiones más lentas
Procesadores menos potentes
Pantallas más pequeñas (CLS más impactante)

Core Web Vitals son especialmente críticos en mobile.

Cargando gráfico...

📊 Lección: Sitios con LCP "Good" tienen 3.2x mejor conversión que sitios "Poor".

Los Umbrales: Good, Needs Improvement, Poor

Cada métrica tiene umbrales específicos:

Cargando gráfico...

⚠️ Importante: Google evalúa basado en el percentil 75 de todas las visitas. Esto significa que el 75% de tus usuarios deben experimentar métricas "Good" para que Google considere tu sitio como "Good".

1. INP (Interaction to Next Paint)

¿Qué es INP?

Definición técnica: El tiempo desde que un usuario interactúa con la página (click, tap, keyboard) hasta que el navegador muestra la siguiente actualización visual.

Definición simple: Qué tan rápido responde tu sitio cuando alguien hace click en un botón, link, o teclea.

INP vs FID: ¿Qué Cambió?

FID (hasta marzo 2024):

Solo medía la PRIMERA interacción
Solo medía el delay antes de procesamiento
No medía el tiempo de procesamiento ni rendering

INP (desde marzo 2024):

Mide TODAS las interacciones durante la visita completa
Mide delay + procesamiento + rendering (end-to-end)
Representa mejor la experiencia real

Ejemplo práctico:

Usuario visita página de producto e interactúa:

Interacción 1: Click en imagen (120ms INP) ✓
Interacción 2: Abrir dropdown de opciones (340ms INP) ✗
Interacción 3: Añadir al carrito (180ms INP) ✓
Interacción 4: Click en checkout (290ms INP) ~

INP reportado: 340ms (el peor)
FID habría reportado: Solo la primera (120ms)

→ INP captura el problema real que FID perdía

Umbrales de INP

┌─────────────────────────────────────┐
│  INP Thresholds                     │
├─────────────────────────────────────┤
│  Good:              ≤ 200ms         │
│  Needs Improvement: 200-500ms       │
│  Poor:              > 500ms         │
└─────────────────────────────────────┘

💡 Realidad: Solo el 65% de sitios tienen INP "Good" (2025 data). Es la métrica más difícil de optimizar.

Cómo Medir INP

Herramienta 1: PageSpeed Insights (Lab + Field Data)

Ve a https://pagespeed.web.dev
Ingresa tu URL
Busca "Interaction to Next Paint" en la sección "Discover what your real users are experiencing"

Field Data (datos reales de Chrome UX Report):

Muestra experiencia de usuarios reales en los últimos 28 días
Solo disponible si tienes suficiente tráfico
Es lo que Google usa para rankings

Lab Data (simulación):

Test sintético en ambiente controlado
Útil para debugging
No representa exactamente experiencia real

Herramienta 2: Chrome DevTools

Abre DevTools (F12)
Ve a Performance tab
Graba interacción (click Record, interactúa, click Stop)
Analiza "Interaction" entries

Busca:

Input delay (tiempo hasta que JavaScript empieza a ejecutar)
Processing time (tiempo ejecutando event handlers)
Presentation delay (tiempo renderizando cambios)

Total INP = Input Delay + Processing Time + Presentation Delay

Herramienta 3: Google Search Console

Ve a Search Console
Core Web Vitals report
Filtra por "INP"

Muestra:

URLs con problemas de INP
Agrupadas por issue similar
Datos de usuarios móviles y desktop

Causas Comunes de INP Alto

Causa #1: JavaScript Bloqueante

Código JavaScript pesado que bloquea el main thread:

// ❌ Problema: Loop costoso bloquea interacción
button.addEventListener('click', () => {
  for (let i = 0; i < 1000000; i++) {
    // Cálculo pesado
  }
  updateUI();
});

Causa #2: Third-Party Scripts

Google Analytics, ads, chat widgets, etc. ejecutándose en el momento de interacción.

Causa #3: Tamaño de DOM Excesivo

Muchos elementos DOM (>1500) hacen el rendering lento.

Causa #4: Tareas Largas (Long Tasks)

Cualquier JavaScript que toma >50ms bloquea el main thread.

Optimizaciones para INP

Optimización #1: Code Splitting

Divide JavaScript en chunks más pequeños:

// ❌ Antes: Todo el código carga upfront
import { heavyFeature } from './heavy-module.js';

button.addEventListener('click', () => {
  heavyFeature();
});

// ✅ Después: Carga solo cuando se necesita
button.addEventListener('click', async () => {
  const { heavyFeature } = await import('./heavy-module.js');
  heavyFeature();
});

Impacto: Reduce initial bundle, mejora tiempo de procesamiento.

Optimización #2: Debouncing y Throttling

Limita frecuencia de ejecución:

// ❌ Problema: Se ejecuta en cada keystroke
input.addEventListener('input', () => {
  expensiveSearch(input.value);
});

// ✅ Solución: Espera 300ms después del último keystroke
const debounced = debounce(() => {
  expensiveSearch(input.value);
}, 300);

input.addEventListener('input', debounced);

Optimización #3: Web Workers

Mueve procesamiento pesado fuera del main thread:

// ✅ Procesa datos en background thread
const worker = new Worker('processor.js');

button.addEventListener('click', () => {
  worker.postMessage(data);
});

worker.onmessage = (e) => {
  updateUI(e.data);
};

Optimización #4: Reducir Tamaño DOM

Target: < 1,500 elementos DOM totales
        < 60 elementos por contenedor
        < 32 niveles de profundidad

Técnicas:

Virtualización (render solo elementos visibles)
Lazy loading de secciones
Evitar DOM manipulation masiva

Optimización #5: Optimizar Event Handlers

// ❌ Problema: Handler complejo
button.addEventListener('click', () => {
  validateForm();
  calculateTotal();
  updateUI();
  trackAnalytics();
  showAnimation();
});

// ✅ Solución: Prioriza feedback inmediato
button.addEventListener('click', () => {
  // Feedback inmediato
  button.classList.add('loading');

  // Trabajo pesado después
  setTimeout(() => {
    validateForm();
    calculateTotal();
    updateUI();
    trackAnalytics();
    showAnimation();
  }, 0);
});

2. LCP (Largest Contentful Paint)

¿Qué es LCP?

Definición: Tiempo que tarda en renderizar el elemento de contenido más grande visible en el viewport inicial.

Elementos que suelen ser el LCP:

Hero image
Video thumbnail
Background image con CSS
Bloque de texto grande (h1)
Elemento de header

Umbrales de LCP

┌─────────────────────────────────────┐
│  LCP Thresholds                     │
├─────────────────────────────────────┤
│  Good:              ≤ 2.5s          │
│  Needs Improvement: 2.5-4.0s        │
│  Poor:              > 4.0s          │
└─────────────────────────────────────┘

Cómo Identificar Tu Elemento LCP

En Chrome DevTools:

Abre DevTools (F12)
Performance tab
Graba carga de página
Busca "LCP" marker en el timeline
Inspecciona elemento marcado

En PageSpeed Insights:

Busca "Largest Contentful Paint element" - te muestra screenshot del elemento.

Causas Comunes de LCP Lento

Causa #1: Imágenes Sin Optimizar

Problema típico:
- Imagen 3MB PNG sin comprimir
- Tamaño de display: 800px
- Carga: 4.2 segundos en 3G

Impacto: LCP de 4.2s → "Poor"

Causa #2: Render-Blocking Resources

CSS y JavaScript que bloquean rendering:

<!-- ❌ Bloquea rendering -->
<link rel="stylesheet" href="styles.css">
<script src="heavy-script.js"></script>

<h1>Contenido importante</h1> <!-- Espera a CSS y JS -->

Causa #3: Slow Server Response Time (TTFB)

Si el servidor tarda >600ms en responder, LCP sufrirá.

Causa #4: Client-Side Rendering

React/Vue/Angular sin SSR:

1. HTML vacío llega (50ms)
2. JavaScript descarga (800ms)
3. JavaScript ejecuta (300ms)
4. Componentes renderizan (200ms)
5. LCP finalmente visible (1350ms total)

Optimizaciones para LCP

Optimización #1: Optimizar Imágenes

Formato:

Usa WebP o AVIF en vez de JPG/PNG:
- WebP: ~30% menor tamaño que JPG
- AVIF: ~50% menor tamaño que JPG

Tamaño:

<!-- ❌ Imagen 2000px para display de 800px -->
<img src="hero-2000px.jpg" width="800">

<!-- ✅ Responsive images -->
<img
  srcset="hero-400px.webp 400w,
          hero-800px.webp 800w,
          hero-1200px.webp 1200w"
  sizes="(max-width: 600px) 400px,
         (max-width: 1200px) 800px,
         1200px"
  src="hero-800px.webp"
  alt="Hero image"
>

Compresión:

JPG: Quality 80-85 (sweet spot)
WebP: Quality 75-80
Herramientas: ImageOptim, Squoosh, Sharp

Optimización #2: Preload Recursos Críticos

<!-- Indica al navegador que cargue imagen LCP inmediatamente -->
<link rel="preload"
      as="image"
      href="hero-image.webp"
      imagesrcset="hero-400px.webp 400w,
                   hero-800px.webp 800w"
      imagesizes="800px">

⚠️ Advertencia: Solo preload el elemento LCP, no todas las imágenes. Preload excesivo empeora performance.

Optimización #3: Eliminar Render-Blocking CSS

Técnica 1: Critical CSS Inline

<head>
  <!-- CSS crítico inline -->
  <style>
    .hero {
      background: #f1f1f1;
      height: 400px;
    }
    /* Solo estilos above-the-fold */
  </style>

  <!-- CSS no crítico con media -->
  <link rel="stylesheet"
        href="styles.css"
        media="print"
        onload="this.media='all'">
</head>

Técnica 2: Remover CSS No Usado

Herramientas:

PurgeCSS
UnCSS
Chrome DevTools Coverage tab

Optimización #4: Optimizar TTFB

Target: TTFB < 600ms

Tácticas:
- CDN (Cloudflare, AWS CloudFront)
- Server-side caching
- Database query optimization
- HTTP/2 o HTTP/3
- Brotli compression

Optimización #5: Server-Side Rendering o Static Generation

Para SPAs (React/Vue/Next.js):

// ❌ CSR: LCP depende de JavaScript
export default function Page() {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetch('/api/data').then(setData);
  }, []);

  return <h1>{data?.title}</h1>;
}

// ✅ SSR/SSG: HTML completo llega inmediatamente
export async function getServerSideProps() {
  const data = await fetchData();
  return { props: { data } };
}

export default function Page({ data }) {
  return <h1>{data.title}</h1>;
}

Impacto: LCP mejora de ~3s a ~1.2s típicamente.

Cargando gráfico...

3. CLS (Cumulative Layout Shift)

¿Qué es CLS?

Definición: Medida de cuánto se mueve el contenido inesperadamente mientras la página carga.

Ejemplo frustrante:

Usuario lee artículo →
Banner de ad carga →
Contenido salta 300px hacia abajo →
Usuario hace click accidentalmente en ad

Esto es exactamente lo que CLS mide.

Umbrales de CLS

┌─────────────────────────────────────┐
│  CLS Thresholds                     │
├─────────────────────────────────────┤
│  Good:              ≤ 0.1           │
│  Needs Improvement: 0.1-0.25        │
│  Poor:              > 0.25          │
└─────────────────────────────────────┘

💡 Nota: CLS no tiene unidad de tiempo, es un score calculado basado en cuánto y qué tan grande es el shift.

Causas Comunes de CLS Alto

Causa #1: Imágenes Sin Dimensiones

<!-- ❌ Navegador no sabe cuánto espacio reservar -->
<img src="photo.jpg" alt="Photo">

<!-- ✅ Dimensiones explícitas -->
<img src="photo.jpg" alt="Photo" width="800" height="600">
<!-- Navegador reserva espacio antes de cargar imagen -->

Causa #2: Ads, Embeds, Iframes Sin Tamaño

<!-- ❌ Ad slot sin altura -->
<div id="ad-slot"></div>
<script>loadAd('#ad-slot');</script>

<!-- ✅ Altura mínima reservada -->
<div id="ad-slot" style="min-height: 250px;"></div>

Causa #3: Web Fonts Cargando (FOIT/FOUT)

Fonts cargando causan:

FOIT: Flash of Invisible Text (texto desaparece, reaparece)
FOUT: Flash of Unstyled Text (cambia fuente)

Ambos causan layout shift si el tamaño cambia.

Causa #4: Contenido Dinámico Inyectado

// ❌ Banner se inserta sin transición
setTimeout(() => {
  document.body.insertBefore(banner, content);
  // Todo el contenido salta hacia abajo
}, 2000);

Causa #5: Animaciones CSS Mal Implementadas

/* ❌ Anima propiedades que afectan layout */
.element {
  animation: expand 0.3s;
}

@keyframes expand {
  from { height: 0; }
  to { height: 300px; }
}
/* Cada frame es un layout shift */

Optimizaciones para CLS

Optimización #1: Dimensiones Explícitas en Todas las Imágenes/Videos

<!-- Always include width & height -->
<img src="image.jpg" width="800" height="600" alt="Description">

<!-- Para responsive, usa CSS -->
<style>
  img {
    max-width: 100%;
    height: auto;
  }
</style>

Navegador calcula aspect ratio y reserva espacio correcto incluso antes de cargar imagen.

Optimización #2: Aspect Ratio Boxes

Para contenido dinámico (ads, embeds):

.ad-container {
  position: relative;
  width: 100%;
  /* 16:9 aspect ratio */
  padding-top: 56.25%; /* (9 / 16) * 100 */
}

.ad-container iframe {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

O usa la propiedad modern aspect-ratio:

.ad-container {
  width: 100%;
  aspect-ratio: 16 / 9;
}

Optimización #3: Optimizar Web Fonts

Técnica 1: font-display

@font-face {
  font-family: 'CustomFont';
  src: url('font.woff2');
  /* Opciones:
     - swap: Muestra fallback inmediatamente, cambia cuando carga
     - optional: Solo usa custom font si carga rápido
     - fallback: Híbrido
  */
  font-display: optional; /* Mejor para CLS */
}

Técnica 2: Preload Fonts

<link rel="preload"
      href="font.woff2"
      as="font"
      type="font/woff2"
      crossorigin>

Técnica 3: Font Matching (Fallback Matching)

@font-face {
  font-family: 'CustomFont';
  src: url('custom-font.woff2');
  /* Define fallback con métricas similares */
  size-adjust: 105%; /* Ajusta para matching similar */
  ascent-override: 95%;
  descent-override: 25%;
}

body {
  font-family: 'CustomFont', Arial, sans-serif;
}

Optimización #4: Reservar Espacio para Contenido Dinámico

// ❌ Inserta sin preparar espacio
fetch('/api/banner')
  .then(html => container.innerHTML = html);

// ✅ Reserva espacio primero
container.style.minHeight = '100px'; // Altura esperada
fetch('/api/banner')
  .then(html => {
    container.innerHTML = html;
    // Quita min-height si es necesario
  });

Optimización #5: Animar Solo Propiedades Compositor

/* ❌ Anima propiedades que causan layout shift */
.element {
  transition: height 0.3s;
}

/* ✅ Usa transform (no causa layout shift) */
.element {
  transform: scaleY(0);
  transition: transform 0.3s;
}

.element.expanded {
  transform: scaleY(1);
}

Propiedades safe para animar:

transform
opacity

Propiedades que causan shifts:

width, height
margin, padding
top, left, right, bottom (sin position: fixed)

Herramientas de Medición Completas

1. PageSpeed Insights

URL: https://pagespeed.web.dev

Qué muestra:

Field Data (usuarios reales, últimos 28 días)
Lab Data (test sintético)
Oportunidades de optimización específicas
Diagnostics detallados

Cuándo usar: Diagnóstico inicial y verificación.

2. Google Search Console - Core Web Vitals Report

Ubicación: Search Console → Experience → Core Web Vitals

Qué muestra:

URLs agrupadas por issue similar
Trend histórico
Separado por Mobile y Desktop

Cuándo usar: Monitoreo continuo, identificar páginas problemáticas.

3. Chrome User Experience Report (CrUX)

Qué es: Dataset público de experiencias reales de usuarios Chrome.

Acceso:

PageSpeed Insights API
BigQuery (para análisis avanzado)
CrUX Dashboard

Cuándo usar: Análisis de industry benchmarks, competitors.

4. Web Vitals Extension (Chrome)

Instalación: Chrome Web Store → "Web Vitals"

Qué muestra:

Badge en browser con estado de cada métrica
Real-time reporting mientras navegas

Cuándo usar: Testing local, debugging.

5. Lighthouse (DevTools)

Acceso: Chrome DevTools → Lighthouse tab

Qué muestra:

Audit completo incluyendo CWV
Performance score
Recommendations específicas

Cuándo usar: Testing durante development.

Plan de Optimización: Priorización

No puedes optimizar todo a la vez. Este es el orden recomendado:

Fase 1: Quick Wins (Semana 1-2)

Prioridad ALTA:

Añadir width/height a todas las imágenes (CLS fix)
Comprimir imágenes existentes (LCP fix)
Implementar lazy loading (LCP fix)
Añadir aspect-ratio a ads/embeds (CLS fix)

Impacto esperado: 30-40% mejora en CLS, 20-30% en LCP

Fase 2: Optimizaciones Técnicas (Semana 3-4)

Prioridad MEDIA:

Implementar critical CSS
Configurar CDN
Optimizar web fonts
Preload recursos críticos
Code splitting básico

Impacto esperado: Adicional 20-30% mejora en LCP

Fase 3: Optimizaciones Avanzadas (Mes 2+)

Prioridad BAJA (pero alto impacto):

Server-side rendering / Static generation
Web Workers para JavaScript pesado
Virtualización de listas largas
HTTP/3 implementation
Advanced caching strategies

Impacto esperado: INP mejora 40-60%, LCP adicional 10-20%

Cargando gráfico...

📊 Lección: CLS y LCP muestran resultados rápidos (semanas 1-2). INP requiere cambios más profundos (mes 2+).

Errores Comunes en Optimización

❌ Error #1: Optimizar Solo en Lab Data

Problema: PageSpeed Insights Lab muestra 90+, pero Field Data es pobre.

Por qué: Lab data es test sintético en condiciones ideales. Field data es usuarios reales con:

Conexiones lentas
Dispositivos viejos
Diferentes navegadores

Solución: Prioriza Field Data (CrUX). Es lo que Google usa para rankings.

❌ Error #2: Ignorar Mobile

Problema: Desktop perfecto, mobile terrible.

Por qué: Mobile-first indexing significa que Google usa versión mobile para ranking.

Solución: Optimiza mobile PRIMERO, luego desktop.

❌ Error #3: Solo Optimizar Homepage

Problema: Homepage pasa, pero páginas de producto/artículos fallan.

Por qué: Google evalúa todo el sitio, no solo homepage.

Solución: Audita páginas de alto tráfico, especialmente:

Páginas de destino principales
Páginas de producto (e-commerce)
Artículos de blog de alto tráfico

❌ Error #4: Sobre-optimizar a Costo de UX

Problema: Remover features útiles para mejorar score.

Ejemplo: Eliminar carousel de imágenes de producto porque afecta CLS.

Solución: Balancea performance con funcionalidad. Algunas veces un CLS ligeramente más alto vale la pena si mejora conversión.

Checklist Final: Antes de Lanzar

Antes de considerar tu sitio "optimizado", verifica:

CLS Checklist

[✓] Todas las imágenes tienen width/height
[✓] Ads tienen aspect-ratio o min-height
[✓] Web fonts usan font-display: optional o swap
[✓] No hay contenido inyectado sin espacio reservado
[✓] Animaciones usan solo transform/opacity

LCP Checklist

[✓] Imágenes optimizadas (WebP, comprimidas)
[✓] Elemento LCP preloaded
[✓] Critical CSS inline
[✓] CSS/JS no crítico deferred
[✓] TTFB < 600ms
[✓] CDN configurado

INP Checklist

[✓] No hay long tasks > 50ms
[✓] JavaScript code-split
[✓] Event handlers optimizados
[✓] Third-party scripts lazy loaded
[✓] DOM size < 1500 elementos

Conclusión

Los Core Web Vitals son más que métricas técnicas: representan experiencia real de usuarios. En 2026, dominar INP (no FID), LCP y CLS es esencial para:

✅ Mejorar rankings en Google ✅ Aumentar conversiones ✅ Reducir bounce rate ✅ Ofrecer mejor experiencia de usuario

Tu próximo paso:

Audita tu sitio con PageSpeed Insights
Identifica qué métrica necesita más atención
Implementa quick wins (Fase 1) esta semana
Monitorea progreso en Search Console

Recuerda: no necesitas score perfecto (100) para rankear bien. "Good" en las tres métricas (75th percentile) es suficiente para pasar el filtro de Page Experience.

Fuentes y Referencias

web.dev: "Interaction to Next Paint (INP)" - https://web.dev/articles/inp
web.dev: "Largest Contentful Paint (LCP)" - https://web.dev/articles/lcp
web.dev: "Cumulative Layout Shift (CLS)" - https://web.dev/articles/cls
Google Search Central: "Page Experience Update" - https://developers.google.com/search/docs/appearance/page-experience
Chrome Developers: "Chrome UX Report" - https://developer.chrome.com/docs/crux

Última actualización: 6 de febrero de 2026