Core Web Vitals en 2026: qué mueve realmente LCP, INP y CLS

La mayoría de los equipos siguen tratando Core Web Vitals como una cifra de Lighthouse que hay que perseguir, no como una arquitectura que hay que corregir. Por eso un sitio puede obtener 95 en PageSpeed Insights y aun así reprobar su evaluación de Core Web Vitals en Google Search Console. Esos dos números miden cosas distintas, y solo uno de ellos afecta el posicionamiento y a los usuarios reales.

Nos vamos a saltar los consejos de plugins. Si tu solución para un problema de rendimiento es "instalar un plugin de caché", estás tratando un síntoma, no la causa. A continuación, lo que realmente mueve cada métrica, y por qué los datos de laboratorio y los datos de campo discrepan con la frecuencia suficiente como para no poder confiar en ninguno de los dos por sí solo.

LCP es un problema de ruta crítica, no un problema de imágenes

Largest Contentful Paint mide el momento en que termina de renderizarse el elemento visible más grande — normalmente una imagen destacada, un titular o un banner. Los equipos recurren por defecto a "comprimir la imagen", y eso ayuda, pero rara vez es el cuello de botella a partir de cierto punto.

La ruta crítica real es esta:

1. Tiempo hasta el primer byte (TTFB). Si tu servidor u origen tarda varios cientos de milisegundos en responder antes de que el navegador tenga algo con lo que trabajar, ninguna compresión de imágenes te va a salvar. El renderizado en el edge, las réplicas de lectura regionales y mover las rutas sensibles al TTFB a la capa de cómputo de un CDN (Cloudflare Workers, Vercel Edge, Lambda@Edge) pueden reducir ese tiempo de forma significativa — cuánto, depende mucho de tu stack, tu región y tu punto de partida.
2. CSS y JS que bloquean el renderizado. Cada hoja de estilos y cada script síncrono que el navegador tiene que analizar antes de poder pintar la página retrasa el LCP. Incluye en línea el CSS crítico para el contenido visible sin necesidad de scroll y difiere el resto.
3. Capacidad de descubrimiento de recursos. El escáner de precarga del navegador necesita encontrar tu imagen LCP cuanto antes. Si se inyecta con JavaScript, se carga desde un background-image de CSS, o queda oculta detrás de una petición de datos del lado del cliente, has retrasado su descubrimiento varios cientos de milisegundos. Usa fetchpriority="high" en la etiqueta <img> real y un <link rel="preload"> para ella.
4. Carga de fuentes. Si tu elemento LCP es texto y estás cargando una fuente web sin ninguna estrategia de fallback, estás añadiendo un round-trip completo antes de que ese texto pueda pintarse. font-display: swap y la precarga resuelven mitades distintas del problema: swap pinta una fuente de reserva de inmediato para que el round-trip no bloquee el LCP (pero puede provocar un reflow visible — y un golpe al CLS — cuando entra la fuente real), mientras que precargar el propio archivo de fuente acorta la descarga para que el cambio ocurra antes. Usa ambas técnicas juntas, no una en lugar de la otra.

Nada de esto es una opción de un plugin. Es enrutamiento, orden del markup y resource hints — decisiones que se toman en tu pipeline de build y en tu HTML, no en un panel de WordPress.

INP es lo que pasa cuando tu arquitectura de JavaScript no escala

Interaction to Next Paint sustituyó a First Input Delay como Core Web Vital en marzo de 2024, y es una métrica más difícil de manipular porque muestrea cada interacción a lo largo de la visita a la página, no solo la primera. Un sitio puede tener un primer clic rápido y aun así reprobar el INP, porque una interacción posterior, después de que se hayan montado suficientes componentes y se haya acumulado suficiente estado, tarda lo bastante en responder como para arrastrar hacia abajo la puntuación p75 — aunque el primer clic se haya sentido instantáneo.

El INP está dominado por la contención del hilo principal (main thread). El navegador no puede responder a un toque o una pulsación de tecla mientras está ocupado ejecutando JavaScript. Las causas habituales:

• Tareas largas. Cualquier cosa que supere los 50ms bloquea el hilo principal e impide que procese la entrada del usuario. Las actualizaciones de estado grandes, los re-renders sin optimizar y los scripts síncronos de terceros (widgets de chat, etiquetas de analítica, ad exchanges) son los culpables más comunes.
• Coste de hidratación. Los frameworks con mucho peso en el cliente que hidratan toda la página al cargar — en lugar de hacerlo de forma progresiva o selectiva — acaparan el hilo principal justo cuando los usuarios empiezan a interactuar. La arquitectura de islas (la hidratación selectiva de componentes aislados de Astro) y la resumability (el enfoque de Qwik, que serializa el estado de ejecución y se reanuda sin volver a ejecutar la lógica de los componentes en absoluto) son dos técnicas distintas que atacan este mismo problema, junto con React Server Components. Si estás usando una SPA totalmente renderizada en el cliente para un sitio de marketing, el INP suele ser donde se nota primero.
• Manejadores de eventos sin agrupar. Una sola entrada que dispara múltiples re-renders síncronos, recálculos de layout o llamadas a la API se acumula rápidamente. El debouncing, usar requestIdleCallback para trabajo no urgente y mover los cálculos pesados a Web Workers ayudan en todos los casos.
• Volumen de scripts de terceros. Los gestores de etiquetas que cargan una docena de scripts adicionales son uno de los principales asesinos del INP, porque no controlas su coste de ejecución, solo si se cargan y cuándo.

El code splitting y el lazy loading basado en rutas reducen el total de JS que se envía, pero el INP premia específicamente mantener el hilo principal libre durante las ventanas de interacción — eso es tanto un problema de scheduling como un problema de tamaño de bundle.

El CLS sigue siendo, sobre todo, un problema de disciplina

Cumulative Layout Shift es la más fácil de corregir de las tres, y es la única que no tiene nada que ver con la infraestructura del servidor. Sus causas son:

• Imágenes y contenido embebido sin width/height explícitos, ni aspect-ratio reservado en el CSS.
• Fuentes web que sustituyen a una fuente de reserva con métricas distintas, provocando un reflow del texto — se mitiga con size-adjust en un bloque @font-face ajustado a tu fuente de reserva.
• Anuncios, banners de cookies y contenido inyectado dinámicamente que empujan hacia abajo el contenido existente después de que se pinta el layout inicial.
• Contenido insertado por encima del contenido existente (un error común de CMS/personalización: un banner inyectado en la parte superior después de que la página ya cargó).

Un CLS por debajo de 0.1 es alcanzable en casi cualquier stack una vez que cada elemento dinámico tiene su espacio reservado. No existe una solución de infraestructura para un atributo width que falta.

Por qué los datos de laboratorio y los datos de campo no coinciden

Esta es la parte que la mayoría de los informes se saltan. Los datos "de laboratorio" de Lighthouse y PageSpeed Insights ejecutan una única carga de página en un dispositivo de gama media simulado, con una conexión limitada artificialmente, con la caché en un estado limpio y sin ninguna variabilidad de usuarios reales. Es reproducible, lo que lo hace útil para pruebas de regresión — pero sigue siendo una instantánea sintética.

Los datos de campo — los que aparecen en el informe de Core Web Vitals de Search Console y en el Chrome UX Report (CrUX) — son una agregación móvil de 28 días en el percentil 75, recopilada de usuarios reales de Chrome, en dispositivos reales, redes reales y estados de caché reales. Es lo que Google realmente usa como señal de posicionamiento.

La brecha se manifiesta de maneras predecibles:

• Mezcla de dispositivos. Tu prueba de laboratorio se ejecuta en un dispositivo simulado fijo. Tus datos de campo incluyen teléfonos Android de gama baja reales con 4G, que siempre mostrarán un INP peor que un perfil sintético de gama media.
• Variabilidad de terceros. Los tests A/B, las plataformas de gestión de consentimiento y las etiquetas publicitarias suelen no dispararse de forma idéntica en un rastreo de laboratorio (que puede no aceptar cookies, activar la geolocalización o cargar redes publicitarias específicas de una región) que en el tráfico real.
• Estado de la caché. Las pruebas de laboratorio se ejecutan a menudo en frío. Los usuarios reales acceden a la caché de tu CDN, a fuentes ya precalentadas y a recursos cargados previamente en visitas repetidas, lo que puede hacer que las herramientas de campo muestren mejores resultados que las de laboratorio — justo lo contrario del patrón habitual.
• Tamaño de muestra y percentil. Una sola ejecución de laboratorio es un solo dato. Los datos de campo en p75 significan que una cuarta parte de tus visitas reales son peores que el número que ves — que es exactamente la cola que las "soluciones rápidas" basadas en plugins nunca tocan.

Trata los datos de laboratorio como un gate de regresión en tu CI, no como un proxy de tu puntuación real. Trata los datos de campo como la verdad de referencia de la que eres responsable, y diagnostícalos con real-user monitoring, no repitiendo ejecuciones de Lighthouse.

Qué priorizar en realidad

Si estás priorizando: corrige primero el CLS (lo más barato y con mayor certeza), corrige después el LCP (cambios de infraestructura y de markup con números claros de antes/después), y trata el INP como una preocupación de arquitectura continua, no como una corrección puntual — vuelve a degradarse cada vez que lanzas un nuevo script de terceros o un árbol de componentes más pesado.

Esta es también la razón por la que el trabajo de Core Web Vitals le corresponde a las personas que escriben y despliegan tu código, no a un checklist de marketing. Nuestro equipo de SEO técnico trata el rendimiento como un problema de ingeniería con un efecto secundario en el posicionamiento, y no al revés — porque así es como realmente funciona el orden de causas.

En resumen: las puntuaciones de laboratorio te dicen si rompiste algo desde ayer. Los datos de campo te dicen lo que tus usuarios y Google realmente experimentaron. Si esos dos números no coinciden, cree en los datos de campo — y ve a arreglar la arquitectura, no la configuración del plugin.