Core Web Vitals 2026: qué son y cómo mejorarlos en tu web.
⏱ 9 min de lectura · Actualizado: marzo 2026
En Colombia más del 70% del tráfico web es móvil, y la mayoría de los sitios locales reprueba al menos una de las tres métricas. Eso no es solo un problema técnico — es una pérdida real de posiciones en Google frente a competidores que sí tienen sus Core Web Vitals en verde. La buena noticia es que mejorarlos es perfectamente manejable cuando se ataca en el orden correcto.
Esta guía explica qué mide cada métrica, cuáles son los umbrales que Google considera aceptables, por qué fallan los sitios colombianos con más frecuencia y qué acciones concretas hay que tomar para corregirlos. Si quieres el contexto más amplio, te recomendamos leer primero nuestra guía de auditoría SEO completa donde los Core Web Vitals son parte del análisis técnico.
- ¿Qué son los Core Web Vitals y por qué importan?
- LCP: Largest Contentful Paint
- INP: Interaction to Next Paint
- CLS: Cumulative Layout Shift
- Umbrales oficiales de Google 2026
- Por qué fallan los sitios colombianos
- Cómo mejorar los Core Web Vitals paso a paso
- Herramientas para medirlos
- Preguntas frecuentes
¿Qué son los Core Web Vitals
y por qué Google los usa como ranking?
Los Core Web Vitals son un conjunto de métricas definidas por Google para medir aspectos concretos de la experiencia que tiene un usuario real cuando visita una página web. No miden opiniones ni suposiciones — miden tiempos y comportamientos reales de los usuarios que llegan a tu sitio, capturados a través del Chrome User Experience Report (CrUX).
Google los convirtió en factor de ranking oficial en mayo de 2021 con la Page Experience Update, y desde entonces los ha refinado continuamente. En 2024 reemplazó la métrica FID por INP, que es más precisa para medir la respuesta a interacciones en sitios modernos con mucho JavaScript. En 2026 los tres indicadores actuales — LCP, INP y CLS — siguen siendo los que determinan si un sitio "pasa" o "reprueba" la evaluación de experiencia de página.
Lo importante es entender que Google no usa tus métricas de laboratorio para el ranking — usa datos reales de usuarios de Chrome. Eso significa que un sitio puede verse rápido en una prueba local con buena conexión, y al mismo tiempo estar fallando en los datos reales porque la mayoría de sus usuarios lo visitan desde móvil con conexión 4G limitada. En Colombia esa diferencia es especialmente marcada.
LCP — Largest Contentful Paint:
la velocidad que el usuario percibe.
El LCP mide cuánto tiempo tarda en cargar el elemento más grande visible en la pantalla — normalmente una imagen principal, un banner hero o un bloque de texto grande. Es la métrica que mejor representa la percepción de velocidad del usuario: el momento en que la página "aparece" y se puede empezar a leer.
Umbral: menos de 2.5 segundos
Un LCP menor a 2.5 segundos es "bueno" según Google. Entre 2.5 y 4 segundos necesita mejoras. Más de 4 segundos es "malo" y genera una penalización en el ranking. En la práctica, la mayoría de sitios colombianos con hosting compartido de bajo costo y sin optimización de imágenes tienen LCPs de 5 a 9 segundos en móvil — muy por encima del umbral.
Causas más frecuentes de LCP alto
El culpable número uno es la imagen del hero o banner principal sin comprimir ni optimizar para web. Una fotografía de 3 MB cargada directamente desde el administrador de WordPress puede subir el LCP de 1.5 a 8 segundos de golpe. Otras causas comunes son el Time to First Byte (TTFB) alto por un hosting lento, el CSS o JavaScript bloqueante que retrasa el renderizado, y las fuentes web que tardan en cargar antes de mostrar el texto.
Cómo mejorar el LCP
El primer paso es convertir todas las imágenes a formato WebP y aplicar lazy loading — excepto la imagen del hero, que debe tener el atributo fetchpriority="high" para que el navegador la cargue de inmediato. Luego hay que activar una CDN (Cloudflare es gratuito), habilitar la caché del servidor y, si el hosting es de bajo rendimiento, migrar a uno con mejor TTFB. En WordPress específicamente, plugins como WP Rocket o LiteSpeed Cache pueden reducir el LCP a la mitad en un par de horas de configuración.
INP — Interaction to Next Paint:
qué tan rápido responde tu sitio.
El INP reemplazó al FID (First Input Delay) en marzo de 2024 porque es mucho más completo. Donde el FID solo medía el primer clic o toque del usuario, el INP mide todas las interacciones durante toda la visita — clics, toques en pantalla, pulsaciones de teclas — y reporta el peor tiempo de respuesta observado durante esa sesión.
Umbral: menos de 200 milisegundos
Un INP menor a 200ms es bueno. Entre 200 y 500ms necesita mejoras. Más de 500ms es malo. Los sitios con mucho JavaScript — tiendas online, sitios construidos con page builders pesados, portales con chat en vivo y múltiples scripts de terceros — son los que más frecuentemente fallan esta métrica. Un solo script de analytics mal cargado puede bloquear el hilo principal del navegador y disparar el INP a 600ms o más.
Cómo mejorar el INP
La estrategia principal es reducir el trabajo del hilo principal del navegador. Eso significa cargar los scripts de terceros (Google Tag Manager, Meta Pixel, chat, mapas) de forma diferida con async o defer, eliminar los scripts que no se usan, y dividir las tareas JavaScript largas en fragmentos más pequeños. En WordPress, revisar qué plugins cargan scripts en todas las páginas y desactivar los que no son necesarios en cada URL específica puede tener un impacto enorme en el INP.
CLS — Cumulative Layout Shift:
la estabilidad visual que evita los clics accidentales.
El CLS mide cuánto se mueven los elementos de la página mientras carga — ese efecto frustrante de intentar hacer clic en un botón y que la página se mueva justo en ese momento, llevando el clic a otro lugar. Google lo mide como la suma de todos los cambios de layout inesperados durante la vida de la página.
Umbral: menos de 0.1
Un CLS menor a 0.1 es bueno. Entre 0.1 y 0.25 necesita mejoras. Más de 0.25 es malo. El CLS es quizás la métrica más fácil de mejorar una vez que se identifican las causas, porque casi siempre se puede corregir con CSS sin tocar el código del servidor.
Cómo mejorar el CLS
La causa más común es imágenes sin dimensiones definidas en el HTML — el navegador no sabe cuánto espacio reservar hasta que la imagen carga, y cuando carga empuja todo el contenido hacia abajo. La solución es agregar atributos width y height a todas las etiquetas img. Los banners publicitarios que cargan después del contenido y los embeds de YouTube o Google Maps sin dimensiones fijas son otros culpables frecuentes.
Umbrales oficiales de Google 2026
para los tres Core Web Vitals.
| Métrica | Bueno ✅ | Necesita mejoras ⚠️ | Malo ❌ |
|---|---|---|---|
| LCP (velocidad de carga) | Menor a 2.5s | 2.5s a 4s | Mayor a 4s |
| INP (respuesta a interacciones) | Menor a 200ms | 200ms a 500ms | Mayor a 500ms |
| CLS (estabilidad visual) | Menor a 0.1 | 0.1 a 0.25 | Mayor a 0.25 |
Google evalúa estas métricas usando datos reales del percentil 75 — es decir, el 75% de las visitas a tu sitio debe cumplir cada umbral para que Google lo considere "bueno". No basta con que el promedio esté bien; si el 25% de tus usuarios experimenta tiempos malos, el sitio sigue reprobando.
¿Por qué fallan los Core Web Vitals
en la mayoría de sitios colombianos?
Hay tres factores estructurales que hacen que los sitios colombianos fallen los Core Web Vitals con más frecuencia que los de mercados más maduros.
Hosting de bajo rendimiento
Muchos sitios colombianos están en planes de hosting compartido muy económicos que tienen tiempos de respuesta del servidor (TTFB) superiores a 2 segundos. Cuando el servidor tarda 2 segundos en responder, el LCP nunca puede ser menor de 2 segundos — sin importar cuánto optimices las imágenes o el código. Un buen hosting con servidor en Colombia o con CDN global es el punto de partida obligatorio para cualquier estrategia de Core Web Vitals.
Construcción con page builders pesados
WordPress con Elementor, WPBakery o Divi carga decenas de archivos CSS y JavaScript adicionales que muchas veces no son necesarios en cada página. Un sitio construido con un page builder y sin optimización puede tener 40 o 50 requests adicionales que bloquean el renderizado. El trabajo de SEO técnico en estos sitios incluye siempre una fase de optimización del pipeline de carga.
Imágenes sin optimizar
Es el problema más común y el más fácil de corregir. Fotografías en formato JPEG o PNG de 2 a 5 MB subidas directamente al gestor de medios de WordPress sin ninguna compresión son el culpable número uno del LCP alto en sitios colombianos. Convertir esas imágenes a WebP y aplicar compresión inteligente puede reducir el LCP entre un 40% y un 60% en muchos casos.
Cómo mejorar los Core Web Vitals
en tu sitio web paso a paso.
Este es el orden de prioridad que seguimos en Webhexup cuando corregimos Core Web Vitals en sitios colombianos:
Medir el estado real con datos de campo
Antes de cambiar cualquier cosa, mide en PageSpeed Insights y en Google Search Console → Experiencia → Core Web Vitals. Usa los datos de campo (CrUX), no los datos de laboratorio. Identifica qué métrica falla más y en qué páginas específicas — no todas tienen el mismo problema.
Optimizar todas las imágenes a WebP
Convierte todas las imágenes del sitio a formato WebP con compresión entre 70% y 80%. En WordPress puedes usar ShortPixel o Imagify para hacer esto de forma masiva en minutos. Agrega width y height a todas las etiquetas img para eliminar el CLS. A la imagen del hero agrégale fetchpriority="high" y elimínale el lazy loading.
Cargar scripts de terceros de forma diferida
Agrega defer o async a todos los scripts que no son críticos para el renderizado inicial — Google Tag Manager, Meta Pixel, chat en vivo, mapas. Cada script de tercero que se carga de forma sincrónica puede bloquear el hilo principal del navegador y disparar el INP. En Google Tag Manager puedes controlar cuándo se activan los tags para reducir el impacto en la carga inicial.
Verificar resultados y monitorear
Los datos de campo en PageSpeed Insights tardan entre 28 y 30 días en actualizarse porque reflejan las últimas 28 días de visitas reales. No esperes ver los resultados al día siguiente de hacer los cambios. Configura alertas en Google Search Console para que te notifique si alguna URL cae a estado "malo" y revisa el informe de Core Web Vitals mensualmente.
Las mejores herramientas para
medir y monitorear Core Web Vitals.
| Herramienta | Para qué sirve | Datos | Costo |
|---|---|---|---|
| PageSpeed Insights | Análisis completo LCP, INP, CLS con diagnóstico | Laboratorio + campo (CrUX) | Gratuita |
| Google Search Console | Estado de Core Web Vitals por URL y grupo | Campo real (CrUX) | Gratuita |
| Chrome DevTools | Diagnóstico profundo de rendimiento en tiempo real | Laboratorio | Gratuita |
| web.dev/measure | Análisis rápido con recomendaciones priorizadas | Laboratorio | Gratuita |
| Ahrefs Site Audit | Monitoreo masivo de Core Web Vitals en múltiples URLs | Laboratorio | Pago |
La diferencia entre datos de laboratorio y datos de campo es crucial. Los datos de laboratorio miden una simulación en condiciones controladas — útiles para identificar problemas pero no son los que Google usa para el ranking. Los datos de campo (CrUX) reflejan las experiencias reales de usuarios en Chrome durante los últimos 28 días, y esos sí son los que determinan tu posición. Si tu sitio tiene poco tráfico, es posible que no tenga datos de campo suficientes y Google use datos de laboratorio como aproximación.