Core Web Vitals en 2026: objetivos de LCP, INP y CLS y cómo alcanzarlos

Los objetivos de Core Web Vitals para 2026 no han cambiado desde 2024. Largest Contentful Paint (LCP) por debajo de 2,5 segundos. Interaction to Next Paint (INP) por debajo de 200 milisegundos. Cumulative Layout Shift (CLS) por debajo de 0,1. Google mide cada métrica en el percentil 75 de las visitas reales, separado por móvil y escritorio, no en una sola prueba de laboratorio. Y en 2024, INP pasó a ser la métrica oficial de interactividad, en sustitución de First Input Delay (FID), algo que conviene saber si tu equipo todavía optimiza contra la métrica anterior.

Qué mide Core Web Vitals en 2026

LCP, INP y CLS, definidos

LCP mide el rendimiento de carga: cuánto tarda en renderizarse el elemento visible más grande de la página, normalmente una imagen destacada o un bloque de titular. El umbral considerado bueno es 2,5 segundos desde que la página empieza a cargar.

INP mide la interactividad. Es el tiempo entre el clic, toque o pulsación de tecla de un usuario y la siguiente actualización visual en pantalla, y el umbral bueno es 200 ms o menos. INP sustituyó a FID como Core Web Vital oficial en 2024, tras un año como métrica experimental. FID solo capturaba el retraso antes de que el navegador empezara a procesar una entrada, no el tiempo completo hasta una respuesta visible, lo que dejaba un vacío real en lo que los equipos estaban optimizando.

CLS mide la estabilidad visual, es decir, cuánto se desplaza el contenido de forma inesperada mientras carga la página. El umbral bueno es 0,1 o menos. Por encima de eso, los usuarios acaban pulsando el botón equivocado, o pierden su sitio a mitad de un párrafo.

La regla del percentil 75, con datos de campo

Lighthouse y otras herramientas de laboratorio ejecutan una única carga de página simulada. Útil para depurar, pero no para cumplir el umbral. La medición real de Google procede del Chrome User Experience Report (CrUX): datos de campo reales de visitas reales. Una página solo cuenta como "buena" en una métrica cuando el 75 por ciento de sus cargas de página cumple ese umbral, medido por separado en móvil y escritorio. Así que una página puede puntuar bien en Lighthouse y aun así aparecer como fallida en Search Console, si los usuarios de móvil con dispositivos más antiguos arrastran los datos de campo hacia abajo.

Por qué Core Web Vitals afecta a los resultados de Google

Core Web Vitals no es un factor de posicionamiento independiente con un valor de puntos fijo. Google lo describe como parte de una señal más amplia de experiencia de página que se alinea con lo que sus sistemas de posicionamiento principales ya premian: las páginas relevantes y bien construidas tienden a cargar y responder rápido de todas formas. Arreglar los Vitals rara vez mueve una página de la posición 20 a la posición 2 por sí solo. Pero una página que falla lo suficiente como para frustrar a los usuarios compite en desventaja, gane o no puntos directamente el algoritmo por ello.

Hay tres herramientas que conviene revisar con regularidad. El informe de Core Web Vitals de Search Console agrupa las URL por estado y señala las regresiones. PageSpeed Insights muestra datos de laboratorio y de campo para una sola URL. El propio conjunto de datos de CrUX es el mejor para el seguimiento de tendencias a nivel de todo el sitio. Trata las puntuaciones de laboratorio como una ayuda de depuración y los datos de campo como la fuente de verdad: una página puede parecer rápida en una sola ejecución de Lighthouse con conexión rápida y aun así fallar su umbral del percentil 75 en cuanto se cuenta el tráfico móvil real en redes más lentas.

Cómo alcanzar tus objetivos de LCP e INP

Sirve bien la imagen de LCP

La palanca más importante para el LCP es asegurarse de que el navegador puede descubrir la imagen principal de inmediato. Tiene que estar en el HTML inicial, ya sea como un <img src> estándar o un <link rel="preload">, y no inyectada después por JavaScript mediante un atributo data-src. Añade fetchpriority="high" y elimina loading="lazy" en esa imagen concreta. Esto importa más de lo que parece: el 73 por ciento de los elementos LCP en móvil son imágenes, y sin embargo solo el 15 por ciento de los sitios usa hoy fetchpriority para priorizarlas.

Reduce el tiempo hasta el primer byte

Una imagen rápida no ayuda mucho si el HTML tarda en llegar. El tiempo hasta el primer byte (TTFB) marca el suelo de todas las métricas que dependen de él: el LCP no puede empezar su cronómetro hasta que el documento comienza a llegar, así que una respuesta lenta del servidor retrasa también toda medición posterior. Servir las páginas desde una CDN, geográficamente cerca del visitante, reduce el TTFB y da a todas las demás métricas un punto de partida mejor. Solo un tercio, aproximadamente, de las solicitudes HTML se sirve hoy desde una CDN, lo que supone una oportunidad real para la mayoría de los sitios, no una optimización de nicho. La generación estática, o la regeneración estática incremental, donde la página se construye antes de la solicitud en lugar de durante ella, elimina la mayor parte del trabajo del lado del servidor de la ruta crítica por completo.

Usa bfcache para visitas repetidas casi instantáneas

La caché de avance/retroceso (bfcache) restaura una página completamente renderizada desde memoria en lugar de recargarla, lo que produce un LCP cercano a cero en la navegación repetida. Mantener la página elegible para bfcache, sin controladores de descarga (unload) y sin Cache-Control: no-store en páginas que no lo necesitan, es una de las mejoras más baratas disponibles.

Mantén libre el hilo principal para el INP

Los problemas de INP son casi siempre problemas de JavaScript. Divide las tareas largas (cualquiera que supere los 50 ms) en fragmentos más pequeños para que el navegador pueda responder a un clic entre medias; la Scheduler API ayuda aquí donde está disponible. Envía menos JavaScript en general y usa la división de código (code-splitting) para que una página solo cargue lo que necesita. Evita los reflujos síncronos forzados. Usa CSS containment para que el contenido fuera de pantalla no compita por tiempo de renderizado.

Lo que Next.js te da por defecto

Si tu stack es Next.js, parte de este trabajo ya está resuelto. El componente next/image integrado ajusta automáticamente el tamaño de las imágenes importadas de forma estática y admite tanto fetchpriority como la carga diferida nativa, lo que cubre una parte importante del trabajo de LCP sin código personalizado. No arregla el TTFB, el peso de JavaScript ni la ubicación de la CDN por sí solo; eso sigue necesitando configuración deliberada. Para un repaso más completo de qué revisar en todo el sitio, consulta nuestra lista de verificación de auditoría técnica SEO para Next.js.

Cómo alcanzar tu objetivo de CLS

Define un width y height explícitos, o un aspect-ratio en CSS, en cada imagen e incrustación. Este único ajuste resuelve la causa más común de desplazamiento de diseño: el 66 por ciento de las páginas incluye al menos una imagen sin dimensiones definidas que empuja el contenido mientras carga. Mantenerse elegible para bfcache también ayuda aquí. Produjo la mayor mejora de CLS registrada en todo el sector tras su despliegue en 2022, ya que una página restaurada no tiene nada que desplazar. Y anima la propiedad CSS transform en lugar de margin, el ancho de border u otras propiedades que afectan al diseño: las páginas que animan propiedades que afectan al diseño muestran problemas de CLS casi al doble de frecuencia que las páginas típicas.

Preguntas frecuentes

¿Cuáles son los umbrales de Core Web Vitals en 2026?

LCP dentro de 2,5 segundos, INP en 200 milisegundos o menos, y CLS en 0,1 o menos, cada uno medido en el percentil 75 de las cargas de página reales.

¿Afecta Core Web Vitals al posicionamiento en Google?

Es una señal más dentro de la experiencia de página de Google, que los sistemas de posicionamiento principales tienen en cuenta junto con la relevancia. No es un factor de posicionamiento independiente.

¿Qué sustituyó a First Input Delay (FID)?

Interaction to Next Paint (INP) pasó a ser la Core Web Vital oficial de interactividad en 2024, en sustitución de FID.

¿Mejora Next.js Core Web Vitals de forma automática?

El componente Image integrado ajusta automáticamente el tamaño de las imágenes importadas de forma estática para evitar el desplazamiento de diseño y admite fetchpriority y carga diferida, pero el TTFB, el peso de JavaScript y la ubicación de la CDN siguen necesitando configuración deliberada.

Conclusión

Los umbrales son fijos y fáciles de comprobar: 2,5 segundos, 200 milisegundos, 0,1, todos medidos frente a visitas reales en lugar de una sola prueba. Las mejoras con más margen a nivel de todo el sector son las de mayor impacto: hacer que la imagen de LCP sea detectable y prioritaria, acercar el HTML a los usuarios, mantener las páginas elegibles para bfcache y dar a cada imagen dimensiones explícitas. Nada de esto requiere una reconstrucción, solo un repaso enfocado por las páginas que más importan. Si quieres que hagamos ese repaso por ti, forma parte de nuestro trabajo de desarrollo web.