Core Web Vitals: Guía Completa para Mejorarlos

Qué son los Core Web Vitals y por qué importan

Los Core Web Vitals son un conjunto de métricas que Google utiliza para medir la experiencia real del usuario en una página web. No son métricas abstractas ni teóricas: reflejan cómo experimentan tu web las personas reales que la visitan.

Desde 2021, Google los incluyó como factor de ranking. En 2026, con la consolidación de INP (Interaction to Next Paint) como métrica oficial desde marzo de 2024, estas tres métricas son más relevantes que nunca para tu posicionamiento orgánico.

Las tres métricas actuales son:

• LCP (Largest Contentful Paint): Mide la velocidad de carga percibida. Cuánto tarda en renderizarse el elemento más grande visible en la pantalla.
• INP (Interaction to Next Paint): Mide la capacidad de respuesta. Cuánto tarda la página en reaccionar visualmente a una interacción del usuario.
• CLS (Cumulative Layout Shift): Mide la estabilidad visual. Cuántos cambios inesperados de diseño ocurren durante la carga y el uso de la página.

Según datos del Chrome UX Report de finales de 2025, solo el 42% de los sitios web cumplen los tres umbrales de Core Web Vitals simultáneamente. Esto significa que más de la mitad de los sitios web están ofreciendo una experiencia subóptima y potencialmente perdiendo posiciones por ello.

Cómo medir los Core Web Vitals correctamente

Antes de optimizar, necesitas medir. Y necesitas entender la diferencia entre dos tipos de datos:

Datos de campo (Field Data)

Son mediciones reales de usuarios que visitan tu web. Google los recopila a través de Chrome y los agrega en el Chrome UX Report (CrUX). Estos son los datos que Google utiliza para evaluar tu web a efectos de ranking.

Se evalúan en el percentil 75: tu puntuación es la experiencia del 75% de tus usuarios. Si el 75% de tus visitantes tienen un LCP inferior a 2,5 segundos, apruebas esa métrica.

Dónde verlos:

• Google Search Console > Core Web Vitals: Vista general de todas tus páginas agrupadas por estado.
• PageSpeed Insights: Datos de campo para URLs individuales (si tienen suficiente tráfico).
• CrUX Dashboard (Looker Studio): Para análisis históricos y tendencias.

Datos de laboratorio (Lab Data)

Son mediciones simuladas en un entorno controlado. No reflejan la experiencia real del usuario, pero son extremadamente útiles para diagnosticar problemas y verificar mejoras antes de desplegarlas.

Dónde obtenerlos:

• Lighthouse (integrado en Chrome DevTools).
• PageSpeed Insights (sección de laboratorio).
• WebPageTest (para análisis más profundo con cascada de red).

Importante: Un error frecuente es optimizar solo para los datos de laboratorio y dar por hecho que los datos de campo mejorarán automáticamente. No siempre es así. Los datos de campo dependen de los dispositivos, conexiones y comportamientos reales de tu audiencia.

LCP: Largest Contentful Paint

Qué es y cómo funciona

El LCP mide cuánto tiempo tarda en renderizarse el elemento de contenido más grande visible en el viewport (la parte visible de la pantalla). Puede ser una imagen, un bloque de texto, un vídeo o un elemento SVG.

Umbrales:

• Bueno: Menos de 2,5 segundos.
• Necesita mejora: Entre 2,5 y 4 segundos.
• Pobre: Más de 4 segundos.

Las 4 causas principales de un LCP lento

1. Tiempo de respuesta del servidor lento (TTFB)

Si tu servidor tarda más de 600 milisegundos en responder, es prácticamente imposible tener un buen LCP. Las causas comunes son hosting compartido de baja calidad, bases de datos sin optimizar y ausencia de caché.

Soluciones:

• Migra a un hosting de mayor rendimiento o utiliza un CDN como Cloudflare.
• Implementa caché a nivel de servidor (Varnish, Redis, caché de página completa).
• Optimiza las consultas a la base de datos y activa la caché de objetos.

2. Bloqueo de renderizado por CSS y JavaScript

El navegador no puede pintar nada hasta que ha procesado todos los archivos CSS críticos. Si cargas hojas de estilo pesadas o JavaScript que bloquea el renderizado, el LCP se retrasa.

Soluciones:

• Extrae e inline el CSS crítico (above-the-fold) directamente en el HTML.
• Carga los archivos CSS no críticos de forma asíncrona.
• Añade defer o async a los scripts que no son esenciales para el renderizado inicial.
• Elimina CSS y JavaScript no utilizado. En muchos sitios, más del 50% del CSS cargado no se usa en la página.

3. Carga lenta de recursos (imágenes, fuentes)

Si el elemento LCP es una imagen (que es lo más habitual), necesitas asegurarte de que se carga lo antes posible.

Soluciones:

• Utiliza formatos modernos como WebP o AVIF. Pueden reducir el tamaño un 30-50% respecto a JPEG.
• Implementa fetchpriority="high" en la imagen LCP para indicar al navegador que la priorice.
• Usa preload para recursos críticos: <link rel="preload" as="image" href="hero.webp">.
• No apliques loading="lazy" a la imagen LCP. El lazy loading es para imágenes below-the-fold.
• Define siempre width y height en las imágenes para que el navegador reserve el espacio.

4. Renderizado del lado del cliente

Las aplicaciones SPA (Single Page Applications) que dependen de JavaScript para renderizar el contenido inicial suelen tener un LCP pobre porque el navegador necesita descargar, parsear y ejecutar JavaScript antes de mostrar nada.

Soluciones:

• Utiliza SSR (Server-Side Rendering) o SSG (Static Site Generation) para generar el HTML en el servidor.
• Implementa hidratación parcial para reducir la cantidad de JavaScript necesario en la carga inicial.
• Frameworks como Astro, Next.js o Nuxt ofrecen estas capacidades de serie.

INP: Interaction to Next Paint

Qué es y cómo funciona

INP (Interaction to Next Paint) reemplazó oficialmente a FID (First Input Delay) en marzo de 2024. Mientras FID solo medía la primera interacción, INP evalúa todas las interacciones del usuario durante la sesión completa y reporta la latencia más alta (con ajustes estadísticos para evitar outliers).

Una “interacción” incluye clics, toques en pantalla y pulsaciones de teclado. El scroll no se considera una interacción para INP.

Umbrales:

• Bueno: Menos de 200 milisegundos.
• Necesita mejora: Entre 200 y 500 milisegundos.
• Pobre: Más de 500 milisegundos.

Por qué INP es más exigente que FID

FID solo medía el retraso antes de que el navegador empezara a procesar la interacción. INP mide el ciclo completo: desde que el usuario interactúa hasta que el navegador pinta la actualización visual en pantalla. Esto incluye:

1. Input delay: El tiempo que la interacción espera en cola porque el hilo principal está ocupado.
2. Processing time: El tiempo que tardan los event handlers en ejecutarse.
3. Presentation delay: El tiempo que tarda el navegador en calcular el layout y pintar la actualización visual.

Según datos de web.dev, cuando se produjo el cambio de FID a INP, muchos sitios que aprobaban con FID suspendieron con INP. La razón es que INP es una métrica mucho más representativa de la experiencia real del usuario.

Cómo mejorar el INP

1. Reduce el trabajo del hilo principal

JavaScript pesado es el enemigo número uno del INP. Cada milisegundo que el hilo principal está ocupado ejecutando JavaScript es un milisegundo que el usuario espera para ver la respuesta a su interacción.

Soluciones:

• Divide las tareas largas (Long Tasks) en tareas más pequeñas usando scheduler.yield() o setTimeout.
• Elimina scripts de terceros innecesarios. Cada widget, tracker o chat que añades compite por el hilo principal.
• Utiliza Web Workers para mover cálculos pesados fuera del hilo principal.

2. Optimiza los event handlers

Si el código que se ejecuta cuando el usuario hace clic es lento, el INP será malo independientemente de lo demás.

Soluciones:

• Evita manipulaciones del DOM innecesarias en los event handlers.
• Usa requestAnimationFrame para separar la lógica de negocio de las actualizaciones visuales.
• Implementa debounce o throttle en interacciones frecuentes como scroll o resize.

3. Minimiza el tamaño del DOM

Un DOM excesivamente grande ralentiza todas las operaciones de layout y pintura. Google recomienda que el DOM no supere los 1.400 nodos.

Soluciones:

• Implementa virtualización para listas largas (solo renderiza los elementos visibles).
• Simplifica la estructura HTML eliminando wrappers innecesarios.
• Carga secciones de contenido bajo demanda cuando son relevantes.

4. Reduce el impacto de los scripts de terceros

Analytics, chats en vivo, pixels de seguimiento, widgets de redes sociales. Cada script de terceros que añades a tu web tiene un coste en INP.

En mi experiencia, el 40-60% del JavaScript que ejecuta una web media proviene de scripts de terceros. Haz una auditoría de todos los scripts que cargas y elimina los que no aporten valor claro.

Soluciones:

• Carga los scripts no esenciales con defer o dinámicamente después de la interacción del usuario.
• Utiliza facades para widgets pesados: muestra una imagen estática del chat o del mapa y carga el widget real solo cuando el usuario interactúa.
• Implementa una política de “presupuesto de JavaScript”: define un límite máximo de KB de JS y no lo superes.

CLS: Cumulative Layout Shift

Qué es y cómo funciona

El CLS mide cuánto se mueve inesperadamente el contenido visible de la página. Esos momentos donde estás leyendo un artículo y de repente el texto salta porque se ha cargado una imagen arriba, o estás a punto de hacer clic en un botón y aparece un banner que desplaza todo.

Umbrales:

• Bueno: Menos de 0,1.
• Necesita mejora: Entre 0,1 y 0,25.
• Pobre: Más de 0,25.

El CLS se calcula multiplicando la fracción de impacto (qué porcentaje del viewport se desplaza) por la fracción de distancia (cuánto se desplaza). Un valor de 0 significa que no hay ningún movimiento inesperado.

Las causas más comunes de un CLS alto

1. Imágenes y vídeos sin dimensiones definidas

Este es el error más frecuente y el más fácil de solucionar. Si no defines width y height en tus elementos <img> y <video>, el navegador no puede reservar espacio antes de cargar el recurso.

Solución: Siempre define las dimensiones de tus imágenes. Con CSS moderno, puedes usar aspect-ratio para mantener las proporciones sin definir tamaños fijos:

img {
  width: 100%;
  height: auto;
  aspect-ratio: 16 / 9;
}

2. Anuncios, embeds y contenido inyectado dinámicamente

Los banners publicitarios son una de las principales causas de CLS en la web. Se cargan después del contenido principal y empujan todo lo demás hacia abajo.

Solución: Reserva espacio fijo para los bloques de publicidad usando contenedores con altura mínima definida. Si no sabes la altura exacta, usa la dimensión más frecuente del anuncio como mínimo.

3. Fuentes web que causan FOUT (Flash of Unstyled Text)

Cuando una fuente web se carga y reemplaza a la fuente del sistema, puede causar un cambio de layout si ambas fuentes tienen métricas diferentes.

Soluciones:

• Usa font-display: optional para evitar el FOUT completamente (la fuente web solo se usa si ya está en caché).
• Usa font-display: swap con size-adjust para que la fuente fallback tenga las mismas métricas que la fuente web.
• Precarga las fuentes más importantes: <link rel="preload" as="font" href="font.woff2" crossorigin>.

4. Contenido inyectado sin reserva de espacio

Banners de cookies, barras de notificación, elementos que aparecen condicionalmente pueden desplazar el contenido si se insertan en el flujo del documento.

Solución: Utiliza position: fixed o position: sticky para elementos que aparecen dinámicamente, de modo que no empujen el resto del contenido. Los banners de cookies, por ejemplo, deberían ir siempre fijos en la parte inferior de la pantalla.

Herramientas para diagnosticar y monitorizar

Para diagnóstico puntual

• Chrome DevTools > Performance: Graba una sesión de carga y analiza exactamente qué causa los problemas. Puedes ver el timeline de tareas del hilo principal, los layout shifts y los eventos LCP.
• Lighthouse: Auditoría completa con recomendaciones específicas. Ejecuta en modo “Mobile” con throttling para simular condiciones reales.
• WebPageTest: Análisis más profundo con cascadas de red, filmstrip de carga y comparativas entre URLs.

Para monitorización continua

• Google Search Console: Panel de Core Web Vitals con datos de campo agrupados por estado. El mejor sitio para ver la foto general.
• CrUX Dashboard: Informes históricos con Looker Studio para ver tendencias a lo largo del tiempo.
• Herramientas RUM (Real User Monitoring): Si necesitas datos más granulares, herramientas como web-vitals.js te permiten recopilar métricas de usuarios reales y enviarlas a tu sistema de analytics.

Plan de acción: prioriza correctamente

Cuando los tres Core Web Vitals necesitan mejora, es importante priorizar. Basándome en mi experiencia, este es el orden que recomiendo:

Prioridad 1: CLS

Es la métrica más rápida de mejorar en la mayoría de los casos. Añadir dimensiones a imágenes, reservar espacio para anuncios y configurar correctamente las fuentes web son cambios que se implementan en horas y tienen efecto inmediato.

Prioridad 2: LCP

Los cambios de LCP (optimización de imágenes, caché, preload) suelen tener un impacto visible en 1-2 semanas una vez que el CrUX acumula suficientes datos nuevos.

Prioridad 3: INP

Es la métrica más compleja de mejorar porque generalmente requiere refactorizar JavaScript. Empieza identificando las interacciones más lentas con Chrome DevTools y aborda las tareas largas una a una.

Impacto real en el SEO

Los Core Web Vitals son un factor de ranking, pero conviene ser realista sobre su peso. No son el factor más importante. El contenido relevante, los backlinks y la autoridad del dominio siguen teniendo más peso en la mayoría de consultas.

Sin embargo, en situaciones de competencia cerrada, los Core Web Vitals pueden ser el factor diferencial. Si dos páginas tienen contenido de calidad similar y perfiles de enlaces comparables, Google favorecerá a la que ofrezca mejor experiencia de usuario.

Además, los Core Web Vitals afectan indirectamente a otras métricas SEO. Una web rápida y estable tiene:

• Menor tasa de rebote (los usuarios no se van frustrados por la lentitud).
• Mayor tiempo de permanencia (navegan más páginas y leen más contenido).
• Mayor tasa de conversión (según Google, por cada segundo de mejora en la velocidad de carga, las conversiones pueden aumentar hasta un 27%).

Mejora la experiencia de tu web

Si tus Core Web Vitals están en rojo o amarillo y no sabes por dónde empezar, podemos ayudarte. En nuestro servicio de diseño y desarrollo web construimos sitios optimizados para el rendimiento desde la base, y con nuestro servicio de SEO nos aseguramos de que la parte técnica de tu web no frene tu posicionamiento.

Solicita una consulta gratuita y analizaremos el estado actual de tus Core Web Vitals con un plan de mejora concreto.