Si tienes una web de empresa en Málaga o Madrid y llevas tiempo preguntándote por qué tu tráfico orgánico no despega a pesar de tener buen contenido, la respuesta puede estar en tres letras: LCP, INP y CLS. Los Core Web Vitals son las métricas que Google usa para evaluar la experiencia real de tus usuarios, y en 2026 su peso en el algoritmo es mayor que nunca.

En este artículo te explicamos qué mide cada métrica, qué ha cambiado con los Core Web Vitals 2026 y cómo puedes saber si tu web está aprobando o suspendiendo, con ejemplos concretos de los errores que vemos en proyectos reales de diseño web.

Qué son los Core Web Vitals y por qué Google los usa como señal de ranking

Los Core Web Vitals son un conjunto de tres métricas de rendimiento que Google introdujo en 2020 para medir la experiencia del usuario de forma objetiva. No son puntuaciones de laboratorio: Google las calcula a partir de datos reales de millones de usuarios de Chrome (el llamado informe CrUX), evaluando el percentil 75 de todas las visitas a tu web.

Dicho de otro modo: no basta con que tu web cargue rápido para ti desde tu oficina. Tiene que cargar rápido para el 75 % de las personas que la visitan, en sus dispositivos reales y con su conexión real.

En 2026, los Core Web Vitals son un factor de ranking confirmado. Para consultas donde el contenido de varios competidores es similar, una web más rápida y estable tiene ventaja real en los resultados de búsqueda.

Las 3 métricas que componen los Core Web Vitals en 2026

Esta es la tabla de referencia rápida:

LCP — Largest Contentful Paint: velocidad de carga

Qué mide: el tiempo que tarda en aparecer en pantalla el elemento más grande y visible de la página. Normalmente es la imagen principal (hero), un vídeo o un bloque de texto grande.

Umbral en 2026: menos de 2,5 segundos es «bueno». Entre 2,5 y 4 segundos, necesita mejora. Por encima de 4 s, la página suspende.

Ejemplo real: imaginemos una web de un negocio sector veterinaria en Málaga tiene una foto de portada de 3 MB sin comprimir y cargada sin prioridad. El LCP se dispara hasta 4,7 segundos en móvil. Resultado: rebote alto y visibilidad reducida en búsquedas locales de «veterinario Málaga».

Los errores más frecuentes que vemos al diseñar webs:

• Imágenes hero en formato JPEG pesado, sin convertir a WebP o AVIF
• Lazy loading aplicado a la imagen principal (que debería cargar de inmediato, no diferida)
• Fuentes web sin font-display: swap que bloquean el renderizado
• Hostings compartidos con TTFB superior a 600 ms

INP — Interaction to Next Paint: capacidad de respuesta

Qué mide: el tiempo que tarda la página en responder visualmente a cualquier interacción del usuario — clics, toques en móvil, pulsaciones de teclado — a lo largo de toda la sesión.

Por qué es el cambio más importante de los últimos dos años: en marzo de 2024, Google reemplazó FID (First Input Delay) por INP. FID solo medía el retraso de la primera interacción. INP mide todas las interacciones durante toda la visita. Es una prueba mucho más exigente.

Umbral en 2026: menos de 200 ms es «bueno». Entre 200 y 500 ms, necesita mejora. Por encima de 500 ms, la página suspende.

Ejemplo real: una tienda online de Madrid (ecommerce de cosmética) tenía una puntuación de FID perfecta y pensaba que su interactividad era correcta. Tras analizar el INP, descubrimos que el botón «Añadir al carrito» tardaba 380 ms en responder porque un script de analítica de terceros bloqueaba el hilo principal. El cliente lo notaba como una web que «se queda parada».

INP es la métrica más difícil de mejorar porque requiere revisar la arquitectura del JavaScript, no solo comprimir imágenes. Si tu web tiene formularios, filtros o botones de compra, INP es tu prioridad.

Dato de 2025: el 77 % de las páginas móviles a nivel global consigue un INP bueno (menos de 200 ms), según el Web Almanac 2025. El 23 % restante está dejando conversiones sobre la mesa.

CLS — Cumulative Layout Shift: estabilidad visual

Qué mide: los movimientos inesperados de elementos en pantalla mientras la página se carga. Cuando un botón o un bloque de texto «salta» porque una imagen o un anuncio se insertó encima, eso es CLS.

Umbral en 2026: menos de 0,1 es «bueno». Entre 0,1 y 0,25, mejorable. Por encima de 0,25, la página suspende.

Ejemplo real: una academia de idiomas online en Madrid tenía un banner de cookies que empujaba todo el contenido de la página hacia abajo al cargarse. Su CLS era de 0,28 y los usuarios hacían clic en el botón equivocado repetidamente. Ajustando el banner a posición fija (overlay) sin desplazar el DOM, el CLS bajó a 0,04 en una semana.

Las causas más comunes de CLS alto que corregimos en proyectos de diseño web:

• Imágenes sin atributos width y height definidos en el HTML
• Banners de cookies que empujan el contenido en lugar de superponerse
• Anuncios o iframes que se insertan dinámicamente sobre el contenido
• Fuentes web que provocan reflow de texto (FOUT)

Constructor de Diseño Web: ¿Cuál Pasa los Core Web Vitals de Google?

Novedades de 2026: el Core Update de marzo y el VSI

El Core Update de marzo de 2026 (lanzado el 10 de marzo, con un despliegue de 19 días) ha reforzado el peso de los Core Web Vitals en el algoritmo de ranking. Sitios que superan los umbrales están viendo mejoras de posición; los que suspenden, caídas.

Además, Google ha empezado a evaluar de forma experimental el llamado Visual Stability Index (VSI), una evolución del CLS que distingue entre desplazamientos esperados (un acordeón que el usuario abre) y desplazamientos inesperados (un anuncio que irrumpe). Los saltos que el usuario puede anticipar dejan de penalizarse; los que no, se penalizan más.

Solo el 47 % de los sitios web en 2026 supera los umbrales «buenos» en las tres métricas. El 53 % restante pierde entre un 8 % y un 35 % de conversiones respecto a su potencial.

Cómo saber si tu web pasa o suspende los Core Web Vitals

Estas son las herramientas que usamos en Reflipa para medir Core Web Vitals con datos reales, no solo de laboratorio:

• Google Search Console → Informe de Experiencia de Página → Core Web Vitals (datos de campo reales de tus usuarios)
• PageSpeed Insights (pagespeed.web.dev) → combina datos de campo CrUX y auditoría de laboratorio con diagnóstico por métrica
• Chrome DevTools → panel Performance para detectar tareas largas que bloquean el hilo principal (clave para INP)

Importante: Google siempre usa datos de campo (CrUX) para el ranking, no los datos de laboratorio. Si PageSpeed te da un 90 pero en Search Console tienes URLs en rojo, el ranking responde al Search Console, no al laboratorio.

Cómo mejoramos los Core Web Vitals en proyectos de diseño web en Reflipa

Cuando diseñamos o rediseñamos una web, los Core Web Vitals no son una fase final: los integramos desde la arquitectura técnica inicial. Estas son las acciones de mayor impacto que aplicamos:

Para mejorar LCP

• Conversión de imágenes a WebP o AVIF con compresión sin pérdida visible
• Añadir fetchpriority=»high» a la imagen hero para que el navegador la cargue primero
• Nunca aplicar lazy loading a la imagen LCP (error muy frecuente en plantillas de WordPress)
• CDN para servir recursos desde servidores cercanos al usuario
• Caché del servidor y compresión Brotli para reducir el TTFB

Para mejorar INP

• Auditar y eliminar scripts de terceros innecesarios (analítica, chatbots, redes sociales)
• Partir el JavaScript en chunks más pequeños (code splitting) para no bloquear el hilo principal
• Usar web workers para cálculos pesados fuera del hilo principal
• Debouncing en eventos frecuentes como scroll o resize

Para mejorar CLS

• Definir width y height en todas las imágenes e iframes en el HTML
• Reservar espacio para anuncios o contenido dinámico antes de cargarlo
• Banners de cookies en posición fija (overlay) sin desplazar el DOM
• font-display: swap + size-adjust en fuentes web para evitar reflow de texto

¿Tu web en está perdiendo posiciones por los Core Web Vitals?

Si tu web tiene más de dos años, es muy probable que no esté optimizada para INP (la métrica más reciente) ni para los umbrales actualizados de 2026. En Reflipa auditamos los Core Web Vitals como parte de cualquier proyecto de diseño web, tanto en páginas nuevas como en rediseños.

Trabajamos con empresas de todos los sectores en Málaga y Madrid — desde consultas médicas hasta ecommerce, pasando por academias, despachos y agencias de eventos — y en todos los casos el punto de partida es siempre el mismo: medir primero, optimizar después, y hacer que los datos de Search Console lo confirmen.

Preguntas frecuentes sobre Core Web Vitals en 2026

¿Los Core Web Vitals afectan al SEO local?

Sí. Las búsquedas locales de tipo «diseño web Málaga» o «páginas web Madrid» también se ven influenciadas por los Core Web Vitals. Si dos webs compiten en el mismo municipio con contenido similar, la que tenga mejor experiencia de usuario tiene ventaja en el ranking.

¿Es suficiente tener un buen resultado en PageSpeed Insights?

No del todo. PageSpeed Insights te da datos de laboratorio útiles para diagnosticar, pero Google usa los datos de campo del informe CrUX para el ranking. Una web puede tener 90/100 en laboratorio y seguir teniendo URLs en rojo en Search Console si sus usuarios reales experimentan lentitud.

¿Cuánto tiempo se tarda en mejorar los Core Web Vitals?

Depende del punto de partida y de los cambios necesarios. Las mejoras de LCP y CLS suelen verse reflejadas en CrUX en 28 días tras la implementación. INP puede requerir más tiempo si hay que refactorizar JavaScript. En proyectos de rediseño web completo, entregamos la web ya optimizada desde el primer día de lanzamiento.

¿Qué pasa si mi web está en WordPress?

WordPress tiene soluciones muy eficaces: WP Rocket o LiteSpeed Cache para cacheo y optimización general, ShortPixel o Imagify para imágenes, y temas ligeros diseñados para rendimiento. El problema más frecuente son los plugins y scripts de terceros acumulados sin revisar. Un buen hosting gestionado también marca una diferencia enorme en el LCP.