Core Web Vitals en 2026: guía completa de optimización para SEO

Los Core Web Vitals son el conjunto de métricas de experiencia de usuario que Google utiliza como factor de posicionamiento en sus resultados de búsqueda. En 2026, estas métricas han madurado hasta convertirse en un criterio de ranking consolidado que ningún equipo de SEO o desarrollo puede ignorar.

Esta guía cubre todo lo que necesitas saber: qué mide cada métrica, cuáles son los umbrales actuales, cómo diagnosticar problemas y, sobre todo, cómo mejorar las puntuaciones de forma sistemática.

¿Qué son los Core Web Vitals y por qué importan para el SEO?

Los Core Web Vitals son tres señales de rendimiento que Google extrae de datos reales de usuarios para evaluar la experiencia de carga, interactividad y estabilidad visual de una página. Forman parte del Page Experience Signal, el conjunto de factores que Google introdujo formalmente como criterio de ranking a partir de 2021.

En 2026, los tres Core Web Vitals activos son:

  • LCP (Largest Contentful Paint): velocidad de carga del elemento visual principal.
  • INP (Interaction to Next Paint): capacidad de respuesta ante interacciones del usuario.
  • CLS (Cumulative Layout Shift): estabilidad visual de la página durante la carga.

Para que una URL reciba la evaluación "Bueno" en Core Web Vitals, las tres métricas deben alcanzar el umbral "Bueno" en el percentil 75 de las visitas reales. Esto significa que el 75 % de los usuarios deben experimentar un rendimiento satisfactorio en cada métrica.

El impacto en el ranking es real aunque sutil: Google aplica estos criterios principalmente como factor de desempate cuando dos páginas tienen calidad de contenido similar. En nichos competitivos, pasar los Core Web Vitals puede suponer la diferencia entre la posición 3 y la posición 8 de la primera página.

LCP (Largest Contentful Paint): rendimiento de carga

Qué mide el LCP

El Largest Contentful Paint mide el tiempo que tarda en renderizarse el elemento de contenido más grande visible en el viewport inicial. Normalmente este elemento es una imagen hero, un banner, un vídeo o un bloque de texto de gran tamaño.

Umbrales de referencia en 2026

Clasificación

Valor LCP

Bueno

≤ 2,5 segundos

Necesita mejora

2,5 – 4 segundos

Malo

> 4 segundos

Google mide el LCP al percentil 75 de las visitas reales registradas en el Chrome User Experience Report (CrUX).

Causas más comunes de LCP deficiente

1. Imágenes sin optimizar. El 90 % de los problemas de LCP tienen origen en imágenes de gran tamaño servidas sin compresión adecuada. Servir imágenes en formatos modernos como WebP o AVIF reduce el peso entre un 30 % y un 50 % sin pérdida de calidad perceptible.

2. Tiempo de respuesta del servidor (TTFB) elevado. Un servidor lento retrasa todos los recursos. Un TTFB superior a 600 ms dificulta alcanzar un LCP menor de 2,5 s.

3. CSS que bloquea el renderizado. Las hojas de estilo en el <head> bloquean el pintado inicial. Extraer el CSS crítico e incrustarlo en el HTML (inline critical CSS) permite que el navegador pinte el elemento LCP sin esperar la descarga completa del CSS.

4. Recursos descubiertos tarde. Si la imagen LCP no está referenciada en el HTML original sino que se inyecta mediante JavaScript o CSS, el navegador la descubre tarde y retrasa el pintado.

Cómo optimizar el LCP paso a paso

  1. Optimiza las imágenes: convierte a WebP/AVIF, añade los atributos width y height, y usa loading="eager" y fetchpriority="high" en la imagen LCP.
  2. Añade un <link rel="preload"> para el recurso LCP principal en el <head> del documento.
  3. Activa la compresión Brotli o Gzip en el servidor web.
  4. Implementa caché de servidor para reducir el TTFB: caché HTTP, Redis, o una CDN con edge caching.
  5. Extrae el CSS crítico e incrústalo en línea; carga el CSS no crítico de forma diferida con media="print".
  6. Mueve el JavaScript no crítico a defer o async para liberar el hilo principal durante la carga inicial.

INP (Interaction to Next Paint): interactividad y respuesta

Qué mide el INP

El Interaction to Next Paint sustituyó definitivamente al FID (First Input Delay) como métrica oficial de interactividad en marzo de 2024 y sigue siendo el estándar en 2026. A diferencia del FID, que solo medía el primer clic del usuario, el INP captura la latencia más alta de todas las interacciones discretas (clics, teclado, taps) a lo largo de toda la sesión de navegación.

La métrica tiene tres componentes internos:

  • Input delay: tiempo entre el evento del usuario y el inicio de los event handlers.
  • Processing time: tiempo de ejecución de los event handlers.
  • Presentation delay: tiempo que tarda el navegador en pintar el frame de respuesta.

Umbrales de referencia en 2026

Clasificación

Valor INP

Bueno

≤ 200 ms

Necesita mejora

200 – 500 ms

Malo

> 500 ms

Según datos del sector, aproximadamente el 43 % de los sitios web siguen suspendiendo el umbral de 200 ms, convirtiendo el INP en la métrica con mayor tasa de fallos en 2026.

Causas más comunes de INP elevado

1. Tareas largas en el hilo principal. El hilo principal de JavaScript ejecuta scripts, gestiona el DOM y procesa eventos. Cuando una tarea ocupa más de 50 ms sin ceder el control, las interacciones del usuario quedan encoladas, disparando el INP.

2. JavaScript de terceros. Scripts de analítica, publicidad, chatbots y widgets externos a menudo ejecutan código en el hilo principal en momentos inopportune. Un solo script de terceros mal integrado puede arruinar el INP de toda una página.

3. Árboles DOM muy grandes. Cuando el DOM supera los 1.500 nodos, las operaciones de estilo y layout se vuelven costosas, incrementando el processing time y el presentation delay.

4. Event handlers ineficientes. Funciones que realizan operaciones síncronas complejas (reordenación de listas, cálculos, lecturas de propiedades que fuerzan reflows) bloqueando el hilo principal durante decenas de milisegundos.

Cómo optimizar el INP

  1. Divide las tareas largas: usa scheduler.yield() (disponible desde Chrome 115) para ceder el control al navegador entre bloques de trabajo y permitir que se procesen las interacciones pendientes.
  2. Aplaza el JavaScript no crítico: utiliza defer, carga condicional, o importación dinámica (import()) para código que no necesita ejecutarse en la interacción inicial.
  3. Mueve trabajo intensivo a Web Workers: las operaciones de cálculo, transformación de datos o filtrado de grandes datasets pertenecen a hilos secundarios, no al hilo principal.
  4. Aplica debouncing y throttling en event listeners de alta frecuencia (scroll, resize, input).
  5. Audita scripts de terceros: mide el impacto individual con Chrome DevTools → Performance, y elimina o sustituye los que bloqueen el hilo principal durante más de 50 ms.
  6. Reduce el tamaño del DOM: fragmenta componentes grandes, usa virtualización para listas largas, y elimina nodos ocultos innecesarios del DOM.

CLS (Cumulative Layout Shift): estabilidad visual

Qué mide el CLS

El Cumulative Layout Shift cuantifica los desplazamientos visuales inesperados que ocurren mientras la página se carga. Cada vez que un elemento se mueve sin que el usuario lo haya provocado (por ejemplo, un botón que salta cuando se inserta un anuncio por encima), se genera una puntuación de layout shift. El CLS es la suma de las peores ráfagas de shifts agrupadas en ventanas de tiempo de cinco segundos.

Una puntuación de CLS alta arruina la experiencia de usuario: el lector pierde el hilo del texto, hace clic en el elemento equivocado o se frustra al ver el contenido moverse sin control.

Umbrales de referencia en 2026

Clasificación

Valor CLS

Bueno

≤ 0,1

Necesita mejora

0,1 – 0,25

Malo

> 0,25

Causas más comunes de CLS elevado

1. Imágenes e iframes sin dimensiones. Cuando el navegador descarga una imagen sin conocer su tamaño de antemano, no puede reservar espacio y el contenido se desplaza cuando la imagen aparece. El Web Almanac 2025 señala que el 62 % de las páginas móviles tienen al menos una imagen sin dimensiones explícitas.

2. Fuentes web (FOUT/FOIT). Si la fuente del sistema y la fuente web tienen métricas diferentes (tamaño, altura de línea, espaciado), el texto salta visualmente al intercambiarse. Esto genera un layout shift medible.

3. Anuncios y banners de contenido dinámico. Los espacios publicitarios sin reserva de altura, los banners de cookies y los pop-ups de consentimiento son fuentes habituales de CLS.

4. Animaciones CSS que desplazan elementos. Animaciones que usan propiedades como top, left, margin o width fuerzan reflows y generan shifts. Las propiedades transform y opacity son compositor-safe y no generan CLS.

Cómo corregir el CLS

  1. Añade siempre width y height a imágenes e iframes: el navegador calculará el aspect ratio y reservará el espacio antes de la descarga.
  2. Usa aspect-ratio en CSS cuando las dimensiones exactas no son fijas pero la proporción sí lo es.
  3. Controla el FOUT de fuentes con font-display: optional (no muestra la fuente web si no está lista) o font-display: swap junto con size-adjust, ascent-override y line-gap-override para alinear las métricas de la fuente de respaldo con la fuente web.
  4. Reserva espacio para anuncios: define una altura mínima en el contenedor publicitario que cubra el tamaño del ad más habitual.
  5. Carga el contenido dinámico debajo del fold o en respuesta a interacciones del usuario (no de forma autónoma mientras el usuario lee).
  6. Sustituye animaciones de layout por animaciones transform-only para elementos que se mueven o redimensionan.

Herramientas de medición de Core Web Vitals

PageSpeed Insights

PageSpeed Insights combina datos reales de campo (CrUX) y datos de laboratorio (Lighthouse). Es el punto de partida más habitual: introduce la URL y obtienes en segundos los valores LCP, INP y CLS con el diagnóstico de las oportunidades de mejora más relevantes.

Google Search Console — Informe Core Web Vitals

Disponible en Search Console → Experiencia → Core Web Vitals. Muestra grupos de URLs con problemas, clasifica por estado (Bueno / Necesita mejora / Malo) y permite identificar patrones (plantillas afectadas, secciones del sitio con peor rendimiento). Es la fuente más fiable para priorizar qué páginas atacar primero.

Chrome UX Report (CrUX)

CrUX es la base de datos de Google con datos reales de rendimiento anonimizados recopilados de usuarios de Chrome. Se actualiza mensualmente y está disponible de forma gratuita a través de la CrUX API, BigQuery y el Data Studio connector. PageSpeed Insights y Search Console lo consumen internamente.

Lighthouse

Lighthouse es la herramienta de auditoría de rendimiento integrada en Chrome DevTools (pestaña Lighthouse). Ejecuta análisis de laboratorio: simula la carga bajo condiciones controladas (red throttled, CPU lenta) e identifica oportunidades de optimización con explicaciones detalladas y estimaciones de impacto.

DebugBear y WebPageTest

Para análisis más avanzados —filmstrips, waterfalls detallados, comparativas antes/después—, herramientas como DebugBear o WebPageTest añaden profundidad diagnóstica que Lighthouse no ofrece.

Datos de campo (CrUX) vs. datos de laboratorio: diferencias clave

Esta distinción es fundamental para interpretar correctamente los resultados:

Aspecto

Datos de campo (CrUX)

Datos de laboratorio (Lighthouse)

Fuente

Usuarios reales de Chrome

Simulación controlada

Representatividad

Refleja la experiencia real de los usuarios

Reproducible, no depende del tráfico

Uso en ranking

Sí — Google usa CrUX para el ranking

No directamente

Disponibilidad

Solo URLs con suficiente tráfico

Cualquier URL, sin mínimo de tráfico

Variabilidad

Varía por dispositivo, red y comportamiento

Consistente entre ejecuciones

Mejor para

Confirmar que los cambios impactan a usuarios

Diagnosticar y reproducir problemas

Regla práctica: usa los datos de laboratorio para diagnosticar y depurar; valida los resultados reales de tus cambios con CrUX a través de Search Console o la CrUX API. Una mejora que solo aparece en Lighthouse pero no mueve los datos de campo no ha tenido impacto real.

Plan de acción para mejorar los Core Web Vitals paso a paso

Fase 1: Diagnóstico (Semana 1)

  1. Descarga el informe de Core Web Vitals de Search Console e identifica los grupos de URLs con estado "Malo" y "Necesita mejora".
  2. Para cada grupo, ejecuta PageSpeed Insights en representantes de muestra y anota los problemas señalados en la sección "Diagnóstico".
  3. Abre Chrome DevTools → Performance y reproduce el flujo de usuario en dispositivo móvil con throttling de red "Slow 4G".
  4. Documenta los tres principales problemas por métrica.

Fase 2: Priorización (Semana 1-2)

Ordena las intervenciones por impacto esperado / esfuerzo:

  • Alto impacto, bajo esfuerzo: añadir dimensiones a imágenes, activar Brotli, añadir preload al recurso LCP.
  • Alto impacto, esfuerzo medio: optimizar y convertir imágenes a WebP/AVIF, implementar inline critical CSS.
  • Alto impacto, esfuerzo alto: refactorizar scripts de terceros, dividir tareas largas en el hilo principal.

Fase 3: Implementación y validación (Semanas 2-6)

  1. Implementa cambios en un entorno de staging.
  2. Mide antes y después con Lighthouse y WebPageTest para confirmar mejoras en laboratorio.
  3. Despliega a producción en grupos de páginas (plantillas similares).
  4. Monitoriza Search Console durante 4-6 semanas para confirmar que los datos de campo mejoran (CrUX se actualiza mensualmente).

Fase 4: Monitorización continua

  • Configura alertas en Search Console para nuevas URLs con estado "Malo".
  • Integra Lighthouse CI en el pipeline de desarrollo para prevenir regresiones antes del deploy.
  • Revisa trimestralmente los datos de CrUX con la API para detectar tendencias.

Conclusión

Los Core Web Vitals en 2026 no son solo una casilla técnica que marcar: representan una manera de medir si tu web realmente sirve a los usuarios de forma eficiente. Un LCP por debajo de 2,5 s garantiza que el contenido principal aparece rápido. Un INP inferior a 200 ms asegura que la página responde con fluidez. Un CLS menor de 0,1 evita la frustración de los saltos visuales inesperados.

La buena noticia es que mejorar estas métricas tiene un doble beneficio: mejora el SEO y mejora la experiencia real del usuario, lo que se traduce en mayor engagement, menor tasa de rebote y mejores conversiones.

¿Necesitas ayuda para optimizar el rendimiento de tu web?

En Comunicua auditamos y optimizamos los Core Web Vitals de tu sitio como parte de nuestra estrategia SEO integral. Si tu web suspende alguna de estas métricas o simplemente quieres saber dónde estás y qué mejorar, contacta con nuestro equipo y te preparamos un diagnóstico sin compromiso.

Sugerencias de enlazado interno

  1. Artículo sobre SEO técnico → enlazar desde la sección "Herramientas de medición" con anchor text "estrategia SEO técnica completa".
  2. Artículo sobre velocidad web y conversión → enlazar desde la introducción o la conclusión con "impacto del rendimiento en la tasa de conversión".
  3. Artículo sobre Google Search Console → enlazar desde la sección "Google Search Console" con anchor text "cómo usar Search Console para el SEO".
  4. Artículo sobre imágenes SEO (alt text, formatos, compresión) → enlazar desde la sección LCP con "optimización de imágenes para SEO".
  5. Artículo sobre JavaScript y SEO → enlazar desde la sección INP con "cómo afecta el JavaScript al posicionamiento".