Saltar al contenido
SEO Toolkit

· SEO Toolkit

Core Web Vitals: la guía completa para medirlos y mejorarlos (2026)

Aprende qué son LCP, INP y CLS, cómo medirlos correctamente y las técnicas concretas para mejorarlos. Con ejemplos reales y prioridades de implementación.

Tu web posiciona en la página 2 con un contenido genial. Tu competidor en la 1 con contenido peor. ¿La diferencia? Su web carga 3 segundos más rápido que la tuya en móvil.

Eso es exactamente lo que miden los Core Web Vitals: la percepción real del usuario sobre la velocidad y calidad de tu web. Y desde 2021 son factor de ranking oficial de Google.

En esta guía te explico qué son, cómo medirlos correctamente (los datos de laboratorio engañan más de lo que ayudan) y las técnicas concretas que mueven la aguja.

Qué son los Core Web Vitals

Los Core Web Vitals (CWV) son tres métricas oficiales de Google que miden la calidad de la experiencia de usuario:

  1. LCP — Largest Contentful Paint → cuánto tarda en aparecer el contenido principal.
  2. INP — Interaction to Next Paint → cuánto tarda tu web en responder a las interacciones.
  3. CLS — Cumulative Layout Shift → cuánto se mueven visualmente los elementos.

Google los introdujo en mayo de 2020 y los hizo factor de ranking en junio de 2021. En marzo de 2024 sustituyó la métrica FID (First Input Delay) por INP, que es más representativa.

Por qué Google los premia

Google quiere mantener a los usuarios contentos. Y un usuario contento es uno que entra en una web rápida, fluida y estable. Los CWV son la traducción técnica de esos tres adjetivos:

  • Rápida → LCP bueno
  • Fluida → INP bueno
  • Estable → CLS bueno

Una web con CWV deficientes frustra al usuario, aumenta el bounce rate y, por extensión, comunica baja calidad a Google.

LCP — Largest Contentful Paint

Qué mide

El tiempo desde que el usuario pide la página hasta que se renderiza el elemento visible más grande. Normalmente: la imagen del hero, un vídeo, o el bloque de texto principal.

Umbrales

ValorCalificación
≤ 2.5 s✅ Bueno
2.5 - 4.0 s⚠️ Necesita mejora
> 4.0 s❌ Deficiente

Causas típicas de LCP malo

  • Imágenes sin optimizar: JPG/PNG cuando podrías usar WebP/AVIF.
  • TTFB alto: el servidor tarda demasiado en responder.
  • CSS/JS bloqueante en el <head>: bloquea el render.
  • Lazy loading mal aplicado: imagen del hero con loading="lazy" (gravísimo).
  • Fuentes web pesadas: bloquean el renderizado del texto.

Cómo mejorar el LCP

1. Optimiza la imagen del hero

<!-- ANTES -->
<img src="/hero.jpg" loading="lazy">

<!-- DESPUÉS -->
<img
  src="/hero.webp"
  width="1200"
  height="630"
  fetchpriority="high"
>
  • Formato WebP/AVIF en lugar de JPG/PNG (60-80% menos peso).
  • Dimensiones correctas: no sirvas 4K para mostrar 800px.
  • fetchpriority="high": prioriza esta imagen sobre el resto.
  • NUNCA loading="lazy" en la imagen del hero.

2. Pre-carga recursos críticos

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<link rel="preload" as="font" href="/fonts/inter.woff2" type="font/woff2" crossorigin>

Le dice al navegador: “descarga esto antes que el resto, lo necesito ya”.

3. Mejora el TTFB

  • Hosting de calidad: VPS o managed hosting > shared hosting básico.
  • CDN: Cloudflare, Vercel, Netlify… reducen latencia geográfica.
  • Caché de página: páginas estáticas pre-generadas en lugar de renderizadas en cada petición.

4. Elimina render-blocking

  • CSS crítico inline en el <head> (solo lo necesario para el primer renderizado).
  • Defer del CSS no crítico: <link rel="stylesheet" media="print" onload="this.media='all'">.
  • Defer del JavaScript: <script defer> o <script async>.

INP — Interaction to Next Paint

Qué mide

Cuánto tarda tu web en responder visualmente cuando el usuario interactúa: clic, tap, escritura. Es el indicador de “qué tan fluida se siente tu web”.

A diferencia de FID (su predecesor), INP mide todas las interacciones de la sesión, no solo la primera. Y reporta la peor.

Umbrales

ValorCalificación
≤ 200 ms✅ Bueno
200 - 500 ms⚠️ Necesita mejora
> 500 ms❌ Deficiente

Causas típicas de INP malo

  • JavaScript pesado bloqueando el hilo principal.
  • Event handlers que hacen tareas largas síncronas.
  • Frameworks que rerenderizan todo en cada cambio.
  • Third-party scripts (analytics, ads, chat) que ralentizan.

Cómo mejorar el INP

1. Reduce el JavaScript

Auditate: ¿usas todo el código de las librerías que cargas? Probablemente no.

  • Tree-shaking: bundlers modernos eliminan código muerto.
  • Code splitting: carga solo el JS de la página actual, no toda la app.
  • Lazy load de componentes: carga features bajo demanda.

2. Divide tareas largas

// ❌ Mal: bloquea el hilo principal 800ms
function processItems(items) {
  for (const item of items) heavyProcess(item);
  updateUI();
}

// ✅ Bien: divide en chunks de 50ms
async function processItems(items) {
  for (let i = 0; i < items.length; i += 100) {
    const chunk = items.slice(i, i + 100);
    chunk.forEach(heavyProcess);
    await new Promise(r => setTimeout(r, 0)); // cede el control al navegador
  }
  updateUI();
}

3. Usa Web Workers

Cálculos pesados (parseo, hashing, manipulación de imágenes) → muévelos a un Web Worker. El hilo principal queda libre para responder a interacciones.

4. Optimiza third-party

  • Bloquea ads y analytics hasta after-load.
  • Carga widgets de chat solo cuando el usuario los necesita.
  • Defer cookies banner que no sea crítico.

CLS — Cumulative Layout Shift

Qué mide

Cuánto se mueven visualmente los elementos durante la carga. Imagina: vas a clicar un botón y, justo cuando bajas el dedo, aparece un anuncio que empuja el botón hacia abajo y clicas otra cosa. Eso es CLS alto.

Umbrales

ValorCalificación
≤ 0.1✅ Bueno
0.1 - 0.25⚠️ Necesita mejora
> 0.25❌ Deficiente

Causas típicas de CLS malo

  • Imágenes sin width y height: el navegador no sabe qué espacio reservar.
  • Anuncios y embeds insertados dinámicamente sin reservar espacio.
  • Fuentes web que cambian el tamaño del texto al cargar (FOUT/FOIT).
  • Cookie banners y pop-ups que aparecen tras la primera carga.
  • Contenido insertado encima del existente (galerías, lazy load mal hecho).

Cómo mejorar el CLS

1. Define dimensiones en imágenes

<!-- ❌ Mal: el navegador no sabe el tamaño hasta que la imagen carga -->
<img src="/foto.jpg" alt="...">

<!-- ✅ Bien: reserva 400x300 desde el principio -->
<img src="/foto.jpg" width="400" height="300" alt="...">

Esto vale incluso si la imagen es responsive (CSS la escala, pero el ratio se mantiene).

2. Reserva espacio para anuncios

.ad-slot {
  min-height: 280px; /* reserva espacio aunque el ad tarde en cargar */
}

Si tu plantilla tiene 3 huecos para AdSense, siempre reserva su altura mínima.

3. Usa font-display correctamente

@font-face {
  font-family: 'Inter';
  src: url('/inter.woff2');
  font-display: swap;
  size-adjust: 100.06%;  /* alinea métricas con la fuente fallback */
  ascent-override: 90%;
  descent-override: 22%;
}

size-adjust y los *-override evitan el “salto” cuando la fuente web sustituye a la del sistema.

4. No insertes contenido encima del existente

  • Pop-ups: usa position: fixed.
  • Cookie banners: idem.
  • Carruseles dinámicos: reserva su altura desde el principio.

Cómo medir tus Core Web Vitals

1. PageSpeed Insights (laboratorio + reales)

pagespeed.web.dev te da:

  • Datos de laboratorio: simulación instantánea para cualquier URL.
  • Datos reales (CrUX): si tu web tiene tráfico suficiente.

Es lo más usado y la fuente que usa nuestro Test de Core Web Vitals.

2. Search Console — Experiencia en la página

Search Console → Experiencia → Core Web Vitals muestra:

  • Cuántas URLs son “Buenas”, “Necesitan mejora” o “Deficientes”.
  • Agrupadas por tipo de problema.
  • Datos reales de Chrome de los últimos 28 días.

Es lo que Google usa para SEO. Es la fuente más importante.

3. Chrome DevTools — Performance Tab

Abre DevTools → Performance → graba una sesión. Ves un waterfall completo de qué bloquea el renderizado.

4. WebPageTest

webpagetest.org te da análisis muchísimo más detallados que PSI, con waterfall, screenshots, comparativas entre runs. Imprescindible para depurar problemas complejos.

5. Real User Monitoring (RUM)

Para webs con presupuesto: instalar herramientas como SpeedCurve, Sentry Performance, Cloudflare Browser Insights. Te dan datos reales de tus usuarios, no del sample limitado de CrUX.

Datos de laboratorio vs datos reales

Esta es la confusión más común del 80% de la gente que mira PageSpeed Insights:

Datos de laboratorio

  • Una simulación que ejecuta Google en una máquina virtual.
  • Condiciones controladas: CPU lenta (4x slowdown), red 3G simulada.
  • Reproducibles: misma simulación = mismos resultados (con ±5% de variabilidad).
  • Disponibles para cualquier URL al instante.

Datos reales (CrUX)

  • Datos de usuarios reales de Chrome de los últimos 28 días.
  • Solo de usuarios que han optado por compartirlos.
  • Reportados como percentil 75 (la experiencia del 75% de tus usuarios).
  • Solo disponibles si tu web tiene tráfico suficiente (~1.000 visitas/mes mínimo).

Cuál usar

Google usa los datos REALES (CrUX) para SEO, no los de laboratorio.

Pero los datos de laboratorio te sirven para:

  • Detectar problemas técnicos antes de tener tráfico
  • Comparar antes/después de optimizaciones
  • Auditar webs ajenas (no tienes acceso a su Search Console)

Estrategia profesional:

  1. Si tu web es nueva, usa datos de laboratorio como guía.
  2. Cuando tengas tráfico real, mira CrUX en Search Console.
  3. Si los reales son malos pero los de laboratorio son buenos → tu web es más rápida en simulación que en la realidad, normalmente porque los datos de laboratorio no incluyen el efecto de scripts third-party (analytics, ads, chats) que se cargan en producción.

Móvil vs escritorio: por qué importa más el móvil

Google indexa con mobile-first desde 2021. Lo que ve Googlebot es la versión móvil, no la de escritorio.

Por tanto:

  • Los CWV que importan para SEO son los de móvil.
  • Una web rápida en escritorio pero lenta en móvil no aprovecha el SEO.
  • Suele ser más fácil ser rápido en escritorio (CPUs potentes, conexiones WiFi). Si optimizas móvil, escritorio mejora gratis.

Plan de optimización: por dónde empezar

Semana 1: Diagnóstico

  1. Pasa nuestro Test de Core Web Vitals sobre tus 5-10 URLs más importantes (móvil + escritorio).
  2. Mira Search Console → Experiencia → Core Web Vitals para ver datos reales.
  3. Identifica el patrón de problemas comunes (LCP malo, CLS alto, INP regular).

Semana 2-3: Quick wins

  • Convierte imágenes a WebP/AVIF (mayor impacto-coste de la lista).
  • Añade width y height a todas las imágenes (5 minutos por imagen).
  • Define min-height en huecos de ads y embeds (15 minutos).
  • Habilita font-display: swap en tus @font-face.

Suele bastar para llevar una web de 30 a 60 puntos de Performance.

Semana 4-6: Optimizaciones medias

  • Pre-carga el LCP element (imagen del hero o fuente principal).
  • Defer scripts no críticos (analytics, ads, chat).
  • Elimina JS no usado (audita con Coverage en DevTools).
  • CSS crítico inline en el <head>.

Aquí pasas de 60 a 80-90 puntos.

Semana 7-12: Optimizaciones avanzadas

  • Code splitting y lazy load de componentes.
  • Optimización del backend (caché, CDN, base de datos).
  • Refactorización de event handlers pesados.
  • Web Workers para cálculos costosos.

Aquí entras en territorio del 95-100. Es donde el ROI baja: muchas horas para ganar pocos puntos. Solo lo justifica si compites en sectores muy duros.

Mitos comunes

”Tener 100/100 en PageSpeed garantiza posicionar mejor”

Falso. Los CWV son uno de los muchos factores de ranking. Tener un 100 no compensa contenido pobre o falta de autoridad. Apunta a verde (≥ 90), no obsesionándote con el 100 perfecto.

”Los anuncios siempre destrozan los Core Web Vitals”

Parcialmente cierto. Los anuncios mal implementados sí. Pero AdSense responsive con espacios reservados, lazy load y defer puede mantener verde el resultado.

”Con un buen hosting es suficiente”

Falso. El hosting solo afecta al TTFB. El LCP, INP y CLS dependen del frontend: imágenes, JS, CSS, layout. Tener un hosting top con un frontend pesado = web lenta.

”Los datos de laboratorio son lo que importa”

Falso. Lo que Google usa es CrUX. Los datos de laboratorio son una herramienta de diagnóstico, no el indicador final.

”Mejorar Core Web Vitals da resultados inmediatos”

Falso. Aunque la web mejore hoy, CrUX necesita 28 días de tráfico real para reflejar el cambio. Y Google necesita 1-3 meses para ajustar tu posicionamiento. Sé paciente.

Conclusión

Los Core Web Vitals son una de las pocas optimizaciones SEO con resultados medibles y factor de ranking oficial:

  • Visible: ves mejoras concretas en tu Search Console.
  • Permanente: una vez optimizado, sigue funcionando años (con mantenimiento mínimo).
  • De doble beneficio: mejor SEO + mejor UX (menor bounce rate).

No te obsesiones con el 100/100, pero no toleres rojos. Una web verde en CWV está en el top 20% de calidad técnica de internet en español.

Tu plan de acción

  1. Mide ahora con nuestro Test de Core Web Vitals.
  2. Implementa los quick wins de las semanas 2-3.
  3. Mide otra vez y comprueba la mejora.
  4. Audita el resto del SEO con nuestro Analizador SEO.
  5. Lee también: