Core Web Vitals en 2026: Explicación de los umbrales de LCP, INP y CLS
Core Web Vitals sigue siendo una señal de ranking confirmada por Google en 2026. Esta guía detalla los umbrales exactos de LCP, INP y CLS, qué causa los fallos y las soluciones más rápidas para alcanzar puntuaciones…
Core Web Vitals son las tres métricas de experiencia de usuario de Google que se utilizan como señal de ranking. En 2026, las métricas son LCP (Largest Contentful Paint), INP (Interaction to Next Paint) y CLS (Cumulative Layout Shift). Alcanzar el umbral de "Bueno" en las tres se correlaciona directamente con una mejor visibilidad en las búsquedas y menores tasas de rebote.
¿Qué son las Core Web Vitals?#
Core Web Vitals son un subconjunto de las señales de Experiencia de Página de Google. Cada métrica cuantifica una dimensión distinta de cómo los usuarios reales perciben una página: velocidad de carga, capacidad de respuesta a la interacción y estabilidad visual. Google las mide utilizando datos de campo recogidos de los usuarios de Chrome y muestra los resultados en Search Console, PageSpeed Insights y el Chrome UX Report (CrUX).
¿Cuál es el umbral de LCP en 2026?#
LCP mide el tiempo que tarda en renderizarse en la pantalla el elemento de contenido visible más grande, normalmente una imagen hero, un gran bloque de texto o un póster de vídeo. Los umbrales son:
- Bueno: ≤ 2,5 segundos
- Necesita mejorar: 2,5 s – 4,0 s
- Malo: > 4,0 segundos
Estos umbrales no han cambiado desde que LCP entró en Core Web Vitals, y Google no ha señalado ninguna revisión para 2026. La barra de 2,5 segundos es deliberadamente agresiva: empuja a los sitios a servir imágenes optimizadas, utilizar una CDN rápida y eliminar los recursos que bloquean el renderizado.
¿Qué causa un LCP lento?
Los principales factores que provocan un LCP lento son:
- Imágenes hero no optimizadas: PNG o JPEG grandes que se sirven sin formatos modernos como WebP o AVIF.
- Recursos que bloquean el renderizado: scripts síncronos o CSS que retrasan la primera pintura del navegador.
- Respuesta lenta del servidor (TTFB): un Time to First Byte superior a ~600 ms consume directamente el tiempo de LCP.
- Carga diferida del elemento LCP:
loading="lazy"en la imagen hero aplaza el activo más importante. - Sin indicación de precarga: no utilizar
<link rel="preload">para la imagen LCP.
Cómo solucionar el LCP
- Identifique el elemento LCP utilizando PageSpeed Insights o la sección "Largest Contentful Paint" de Chrome DevTools.
- Convierta la imagen a WebP o AVIF y sírvala con el tamaño de visualización correcto.
- Añada
<link rel="preload" as="image">para la imagen LCP en el<head>. - Trasládese a un host o CDN con un TTFB inferior a 200 ms en el percentil 75.
- Elimine o aplace cualquier script que bloquee el renderizado above the fold.
¿Cuál es el umbral de INP en 2026?#
INP sustituyó a First Input Delay (FID) como Core Web Vital en marzo de 2024 y sigue siendo la métrica de interactividad en 2026. INP mide la latencia de todas las interacciones del usuario —clics, pulsaciones y eventos de teclado— a lo largo de todo el ciclo de vida de la página, y luego informa del valor del peor caso en el percentil 98.
- Bueno: ≤ 200 milisegundos
- Necesita mejorar: 201 ms – 500 ms
- Malo: > 500 milisegundos
A diferencia de FID, que sólo medía la primera interacción, INP penaliza cualquier interacción lenta durante una visita. Esto hace que sea mucho más representativo de la frustración real del usuario.
¿Qué causa un INP alto?
- Tareas largas en el hilo principal: JavaScript que bloquea el hilo principal durante más de 50 ms retrasa el procesamiento de la entrada.
- Controladores de eventos pesados: listeners onClick u onChange que desencadenan actualizaciones DOM costosas.
- Scripts de terceros: analíticas, widgets de chat y scripts de anuncios que compiten por el tiempo del hilo principal.
- Coste de hidratación en las SPA: Sitios React, Vue o Angular que rehidratan grandes árboles de componentes en la carga.
Cómo solucionar el INP
- Abra Chrome DevTools → panel Rendimiento → grabe una interacción e identifique las tareas largas.
- Divida las tareas largas en trozos más pequeños utilizando
scheduler.yield()osetTimeout(..., 0)para ceder al navegador. - Audite los scripts de terceros con los paneles Cobertura y Red; aplace o elimine los que no sean críticos.
- Utilice
startTransition(React) o las API de framework equivalentes para restar prioridad a las actualizaciones de estado no urgentes. - Minimice el tamaño del DOM: las páginas con decenas de miles de nodos tienen un recálculo de estilo más lento después de cada interacción.
¿Cuál es el umbral de CLS en 2026?#
CLS mide los cambios visuales inesperados: elementos que saltan mientras la página se carga. Se puntúa como un agregado sin unidades de todos los cambios de diseño no causados por la entrada del usuario.
- Bueno: ≤ 0,1
- Necesita mejorar: 0,1 – 0,25
- Malo: > 0,25
Un CLS de 0,1 puede sonar abstracto, pero en la práctica significa que el impacto combinado de los cambios debe ser pequeño en relación con el viewport. Un único banner grande o una imagen sin tamaño pueden llevar una página a la banda de "Malo" al instante.
¿Qué causa un CLS alto?
- Imágenes sin atributos
widthyheight: el navegador no puede reservar espacio antes de que la imagen se cargue. - Contenido inyectado dinámicamente: anuncios, banners de cookies o ventanas emergentes de boletines que empujan el contenido hacia abajo.
- Fuentes web que causan FOUT/FOIT: intercambios de fuentes que cambian las longitudes de línea y redistribuyen los bloques de texto.
- Incrustaciones de carga tardía: iframes para YouTube o Twitter que no tienen un contenedor de relación de aspecto reservado.
Cómo solucionar el CLS
- Especifique siempre
widthyheighten las etiquetas<img>, o utiliceaspect-ratioen CSS. - Reserve espacio para los espacios publicitarios con un contenedor de altura mínima incluso antes de que se cargue el anuncio.
- Utilice
font-display: optionalo precargue las fuentes web críticas para evitar los intercambios tardíos. - Envuelva los iframes en un contenedor CSS de relación de aspecto (truco
padding-topoaspect-ratio: 16/9). - Evite insertar contenido por encima del contenido existente después de la carga inicial.
¿Cómo se miden las Core Web Vitals?#
Google utiliza datos de campo (mediciones de usuarios reales de CrUX) como señal de clasificación, no datos de laboratorio. PageSpeed Insights muestra ambos, pero sólo los datos de campo afectan a las clasificaciones. Una página necesita pasar las tres métricas en el percentil 75 de las cargas de página para ser considerada "Buena" para la experiencia de página.
Las herramientas de laboratorio —Lighthouse, WebPageTest— son inestimables para el diagnóstico, pero no pueden sustituir a los datos de CrUX. Si CrUX no tiene suficiente tráfico para una URL, Google agrega a nivel de origen.
Cómo supervisar las Core Web Vitals a escala#
Para sitios con cientos o miles de páginas, la comprobación manual es poco práctica. El enfoque correcto:
- Search Console → Informe de Core Web Vitals: vista agrupada de las URL Buenas / Necesita mejorar / Malas por métrica.
- CrUX API o BigQuery: extraiga datos de campo brutos programáticamente para paneles personalizados.
- Monitorización de usuarios reales (RUM): bibliotecas como
web-vitals.jsenvían LCP, INP y CLS de sesiones reales a sus analíticas. - Auditorías automatizadas: herramientas como SeoChatAI pueden mostrar los problemas de Core Web Vitals junto con las auditorías técnicas de SEO, accesibilidad y preparación para la IA en una sola pasada.
¿Aprobar las Core Web Vitals garantiza una mejor clasificación?#
Aprobar las tres métricas en el umbral de "Bueno" es una condición necesaria pero no suficiente para las primeras posiciones. Core Web Vitals es una señal de desempate: cuando la calidad del contenido, la relevancia y la autoridad son iguales, la página con mejores señales de experiencia se clasificará más alto. Google nunca ha revelado el peso exacto, pero la señal es real y está documentada en su documentación de los sistemas de clasificación.
La conclusión práctica: arregle las Core Web Vitals para eliminar un suelo de clasificación, luego céntrese en el contenido y la autoridad para romperlo.
Core Web Vitals y la búsqueda con IA en 2026#
A medida que las generalizaciones generadas por la IA (antes SGE) aparecen ahora en los resultados de la búsqueda de Google, las señales de experiencia de la página influyen en si una página se cita como fuente. Las páginas que son lentas, visualmente inestables o que no responden tienen menos probabilidades de ser destacadas. La ejecución de una auditoría completa del sitio a través de SeoChatAI le ofrece una visión combinada de sus puntuaciones CWV, la preparación de los datos estructurados y la elegibilidad para la cita de la IA, lo que es cada vez más relevante a medida que los motores de respuesta de la IA superan a los clics tradicionales de enlaces azules.
Referencia rápida: Umbrales de Core Web Vitals en 2026#
| Métrica | Bueno | Necesita mejorar | Malo |
|---|---|---|---|
| LCP | ≤ 2,5 s | 2,5 s – 4,0 s | > 4,0 s |
| INP | ≤ 200 ms | 201 ms – 500 ms | > 500 ms |
| CLS | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Todos los umbrales se aplican en el percentil 75 de los datos de campo. Una sola página con un puñado de cargas muy lentas puede llevar el agregado al territorio de "Malo", razón por la cual la supervisión a nivel de percentil importa más que las puntuaciones medias.
