Core Web Vitals 2026: guía práctica de optimización
LCP, INP y CLS explicados de forma sencilla, con las novedades de 2026 y estrategias concretas para que tu sitio sea más rápido y más estable.
Desde 2021 Google usa las Core Web Vitals como señal de posicionamiento dentro de la «experiencia en la página». Las métricas son tres y los umbrales no han cambiado: lo que ha cambiado en 2026 es, sobre todo, cómo se miden. Veamos qué miden, qué hay de nuevo y cómo mejorarlas de forma concreta.
Las tres métricas fundamentales
LCP — Largest Contentful Paint
Mide cuánto tarda en mostrarse el elemento visible más grande de la página (normalmente la imagen principal o un bloque de texto). Objetivo: en 2,5 segundos o menos. Entre 2,5 y 4 segundos «necesita mejorar»; por encima, es «deficiente».
INP — Interaction to Next Paint
Sustituyó a FID en marzo de 2024. Mide la capacidad de respuesta: cuánto tiempo pasa entre una interacción (clic, toque, escritura) y el momento en que la página muestra una respuesta visual. Objetivo: 200 milisegundos o menos. A diferencia de FID, tiene en cuenta todas las interacciones de la visita, no solo la primera.
CLS — Cumulative Layout Shift
Mide la estabilidad visual: cuánto se desplazan los elementos mientras la página carga. Texto que salta, botones que cambian de sitio justo cuando vas a tocarlos. Objetivo: por debajo de 0,1.
Para superar la evaluación, Google mira el percentil 75 de las visitas reales: al menos tres de cada cuatro visitas deben quedar dentro del umbral, por separado en móvil y en escritorio.
Qué cambia en 2026
La principal novedad afecta a los sitios creados como single-page application (React, Vue, Angular y similares). Hasta ahora, al cambiar de página sin recargar el documento, el navegador seguía atribuyendo las métricas a la URL inicial. Desde Chrome 151, publicado en agosto de 2026, estas «soft navigations» se miden por defecto: cada cambio de página tiene sus propios LCP, INP y CLS.
Dos matices. Google todavía no ha decidido cómo se incorporarán estas mediciones al Chrome UX Report, la base de datos que usan PageSpeed Insights y Search Console. Y los umbrales siguen siendo los de siempre: circulan artículos sobre un LCP «rebajado a 2 segundos» o una evaluación «por dominio», pero la documentación oficial de Google no dice nada parecido.
Las causas más habituales de un LCP alto
- Una imagen principal pesada o sin fetchpriority="high"
- Una imagen principal con carga diferida (lazy loading): hay que evitarla en la parte visible de la página
- Fuentes cargadas desde servicios externos de forma bloqueante
- TTFB alto: servidor lento, sin caché, sin CDN
- CSS y JavaScript que bloquean el renderizado en el <head>
- Imágenes en JPEG o PNG donde WebP o AVIF pesarían mucho menos
Cómo mejorar el LCP
La intervención más eficaz casi siempre afecta a la imagen principal: un formato moderno (WebP o AVIF), tamaños adaptados a la pantalla con srcset, fetchpriority="high" y nada de lazy loading. Si la imagen está definida en el CSS, un <link rel="preload"> en el <head> permite al navegador descubrirla enseguida.
Segunda prioridad: el servidor. Una página que llega a los 1,5 segundos ya ha consumido más de la mitad del tiempo disponible. La caché de páginas, la compresión y una CDN reducen el TTFB más que cualquier optimización del front-end. Por último, alojar las fuentes en tu propio dominio elimina una conexión externa, especialmente costosa en redes móviles.
Cómo mejorar el INP
El INP suele ser la métrica más difícil, porque depende de cuánto JavaScript ejecuta el navegador en el hilo principal. Las estrategias que funcionan:
- Reducir los scripts de terceros (chat, widgets, píxeles publicitarios) y cargarlos solo donde hacen falta
- Dividir las tareas largas, devolviendo el control al navegador con scheduler.yield() donde esté disponible y setTimeout como alternativa
- Mostrar enseguida una respuesta visual a la interacción y aplazar el trabajo pesado
- Cargar los scripts no críticos con defer o async
- Evitar DOM enormes: las páginas con miles de nodos ralentizan cada actualización
Cómo mejorar el CLS
El CLS suele ser el más fácil de resolver. La mayoría de los problemas vienen de:
- Imágenes y vídeos sin width y height: el navegador no reserva el espacio
- Fuentes web que, al cargarse, cambian el tamaño del texto: font-display: swap ayuda, pero para eliminar el desplazamiento hace falta una fuente de reserva con métricas similares (size-adjust)
- Banners, anuncios y widgets insertados sin un espacio reservado
- Contenido añadido dinámicamente por encima del que ya se ve
En una auditoría del sitio de un cliente redujimos el CLS de 0,42 a 0,02 simplemente añadiendo width y height explícitos a todas las imágenes y corrigiendo la carga de las fuentes.
Herramientas para medir
PageSpeed Insights sigue siendo el punto de partida, pero muestra dos cosas distintas: datos de laboratorio (una simulación) y datos reales de los usuarios de Chrome de los últimos 28 días. Para la evaluación de Google cuentan los segundos. El informe de Core Web Vitals de Search Console agrupa las páginas con problemas similares, y el panel Performance de Chrome DevTools es imprescindible para descubrir qué interacción provoca un INP alto. Para un seguimiento continuo, la librería web-vitals recoge las métricas directamente de los usuarios reales.
Conclusión
Las Core Web Vitals no son solo métricas de posicionamiento: son un indicador de la experiencia real de quien visita tu sitio. Un sitio rápido y estable convierte mejor y retiene más. Y la optimización no se hace una sola vez: hay que vigilarla con el tiempo, sobre todo después de cada publicación o actualización de contenidos.