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

Las Core Web Vitals son la respuesta medible de Google a una pregunta sencilla. ¿Esta página se siente realmente rápida para una persona real en un teléfono real? Las puntuaciones de laboratorio pueden mentir, las afirmaciones de marketing pueden mentir, pero los datos de tiempo capturados de usuarios reales de Chrome en el campo dicen la verdad. Ese conjunto de datos es lo que las Core Web Vitals reportan, y es la razón por la que estas métricas se mantienen mientras tantas otras iniciativas de Page Experience han desaparecido.

En 2026 el conjunto está fijo. LCP mide la carga. INP mide la interactividad. CLS mide la estabilidad visual. Las tres juntas cubren los momentos en los que los usuarios notan un sitio lento. Esta guía recorre cada métrica, los umbrales que importan, la diferencia entre lab y field, el playbook que arregla cada una, y la respuesta honesta a la pregunta que todo equipo termina haciendo: ¿cuándo mueven realmente el ranking las Core Web Vitals?

Las tres métricas en 2026

Google agrupa las Core Web Vitals en tres métricas con nombre, una por cada categoría de rendimiento percibido por el usuario.

Largest Contentful Paint (LCP) captura la carga. El reloj arranca en el momento en que el usuario solicita la página y se detiene cuando el elemento de contenido visible más grande termina de pintar. Ese elemento suele ser la imagen principal, un banner o un titular grande.

Interaction to Next Paint (INP) captura la interactividad. INP reemplazó a First Input Delay (FID) en marzo de 2024. Mientras FID solo medía la primera interacción, INP mide cada interacción a lo largo de la sesión y reporta el retraso más largo. Ese cambio importa porque la mayoría de los usuarios tiene un primer clic fluido y luego se topa con un tercer o cuarto tap entrecortado. INP capta justo los momentos malos que FID nunca veía.

Cumulative Layout Shift (CLS) captura la estabilidad visual. CLS es la suma de los cambios de diseño inesperados durante la sesión. Un botón que baja en la pantalla mientras se carga un anuncio lento por encima, una receta que salta media pantalla cuando entra una tipografía, ambos generan CLS. Los cambios de diseño son justo el tipo de bug que un desarrollador apenas nota en un portátil rápido, y exactamente el tipo que un usuario real siente cada día en un teléfono más lento.

Estas tres métricas comparten dos decisiones de diseño que explican por qué se han convertido en estándar. Son percibidas por el usuario, no técnicas. Y se reportan desde usuarios reales de Chrome a través del Chrome User Experience Report (CrUX), no desde corridas sintéticas de laboratorio. Las dos decisiones son deliberadas. Métricas anteriores como Time to First Byte y First Contentful Paint eran proxies técnicos que no siempre coincidían con lo que sentían los usuarios. Las Core Web Vitals intentan medir esa sensación misma.

Largest Contentful Paint (LCP)

LCP marca el momento en el que la página se vuelve visualmente significativa. Si el elemento más grande sigue cargando, el usuario sigue esperando. Si ya pintó, puede engancharse.

Los umbrales LCP para 2026, fijados por Google, no han cambiado.

• Bueno: 2,5 segundos o menos
• Necesita mejorar: 2,5 a 4,0 segundos
• Pobre: más de 4,0 segundos

El percentil 75 es lo que cuenta. Google mira el valor de LCP en el percentil 75 de sus visitantes reales en una ventana de 28 días. Si el 75 por ciento de sus usuarios reales ve LCP en 2,5 segundos o menos, la página es buena. Si solo la mediana llega a ese valor y el percentil 75 está en 5 segundos, la página es pobre.

El elemento más grande lo identifica el navegador en vivo. En una página típica de contenido suele ser la imagen principal, una foto destacada o un titular grande. En páginas de comercio suele ser la imagen principal del producto. En una página de inicio con video, la imagen del póster del video toma ese papel.

Las causas habituales de un LCP lento caen en cinco grupos.

Respuesta lenta del servidor. Time to First Byte forma parte de LCP. Si el servidor tarda 800 ms en enviar el primer byte, LCP no puede empezar antes. El tiempo de respuesta del servidor depende de su hosting, su CDN y de cuánto trabajo hace el servidor antes de responder.

Recursos que bloquean el render. Los archivos CSS en el head y el JavaScript sin async o defer bloquean el pintado del navegador. Cada recurso bloqueante es un retraso que se suma a LCP.

Carga lenta del recurso. La propia imagen más grande tarda en descargarse. Una imagen principal de 2 MB en una conexión lenta agrega segundos. La solución son los formatos de imagen modernos (WebP, AVIF), un tamaño correcto para el viewport y la pista de carga adecuada.

Render del lado del cliente. Una página que no pinta nada hasta que JavaScript se ejecuta y trae datos tiene un LCP igual al tiempo de arranque del JavaScript. Las single page applications sin renderizado del lado del servidor muestran con frecuencia LCP por encima de 4 segundos en teléfonos reales.

Carga de tipografías. Un elemento de texto tardío promovido a LCP puede esperar a una webfont. Font display swap y un fallback con size adjusted evitan que el texto quede retenido.

La secuencia de arreglo para LCP es siempre la misma. Identificar el elemento LCP. Medir cómo se carga. Eliminar el eslabón más lento de esa cadena.

Interaction to Next Paint (INP)

INP se convirtió en la métrica oficial de interactividad en marzo de 2024, reemplazando a FID. La diferencia clave: FID medía solo la primera entrada, INP mide cada entrada y reporta la peor.

Los umbrales INP para 2026 también son estables.

• Bueno: 200 ms o menos
• Necesita mejorar: 200 a 500 ms
• Pobre: más de 500 ms

INP se reporta como la peor (o casi peor) latencia de interacción observada en la sesión. El navegador rastrea cada clic, tap y pulsación de tecla, mide el tiempo desde la entrada hasta el siguiente paint, y entrega la más larga como el INP de la página para esa sesión.

INP falla por una razón. El main thread está bloqueado cuando el usuario interactúa. JavaScript corre en el main thread, el layout corre en el main thread, el paint corre en el main thread. Si una tarea larga de JavaScript está en curso cuando el usuario hace clic, el clic queda en cola hasta que la tarea termina. El resultado visible es un botón que no responde durante medio segundo.

Las cinco causas habituales de un INP pobre.

Tareas largas de JavaScript. Una función que corre 300 ms bloquea el main thread durante 300 ms. Los responsables habituales son los grandes bucles síncronos, la deserialización de payloads JSON pesados y los recálculos complejos de estado en single page apps.

Scripts de terceros. Analytics, publicidad, A/B testing, gestores de etiquetas. Cada uno carga en el main thread, cada uno puede disparar una tarea larga en momentos imprevisibles.

Manejadores de eventos pesados. Un click handler que hace demasiado trabajo en una sola función. Clic dispara cambio de ruta, cambio de ruta carga datos, los datos disparan un render pesado. El usuario hizo un clic y esperó 600 ms.

Tormentas de render en React o Vue. Un cambio de estado que dispara el re-renderizado del árbol completo, mientras el usuario está a media pantalla o a medio tap.

Animaciones que se atascan durante la interacción. Una transición CSS o una animación JavaScript que retiene el main thread mientras el usuario intenta hacer scroll o clic.

El kit para arreglar INP está bien establecido. Romper las tareas largas en piezas más pequeñas usando scheduler.yield(), requestIdleCallback o un simple setTimeout(fn, 0). Mover el trabajo pesado a un Web Worker. Diferir scripts de terceros no críticos detrás de la interacción del usuario. Memoizar componentes de React y usar useDeferredValue para estado no urgente. Auditar qué corre de forma síncrona en cada interacción y decidir qué puede correr más tarde.

Cumulative Layout Shift (CLS)

CLS mide la inestabilidad visual de la página. Cada vez que algo se mueve en la pantalla de forma inesperada, CLS sube. La métrica no tiene unidades, se calcula como la suma de los puntajes de cambio de diseño durante la sesión.

Los umbrales CLS para 2026.

• Bueno: 0,1 o menos
• Necesita mejorar: 0,1 a 0,25
• Pobre: más de 0,25

Un puntaje individual de cambio de diseño es el factor de impacto multiplicado por el factor de distancia. Una imagen que empuja media página hacia abajo en un diez por ciento del viewport puntúa 0,05. Dos cambios así en una sesión suman 0,10, justo en el borde. Tres llevan la página al rango pobre.

Las cuatro causas que producen la gran mayoría de los problemas de CLS.

Imágenes y videos sin dimensiones. Cuando el navegador no conoce el tamaño de una imagen hasta que la carga, no reserva espacio, pinta el contenido alrededor y desplaza todo hacia abajo cuando la imagen llega. Ponga siempre width y height en imágenes y videos, o use el equivalente de aspect ratio en CSS.

Contenido insertado de forma dinámica. Anuncios, embeds, banners y notificaciones añadidos al DOM después del render inicial empujan todo lo que está debajo. La solución es reservar espacio por adelantado, incluso cuando el contenido aún no se ha cargado, fijando una altura mínima en el contenedor.

Webfonts que entran tarde. Cuando una webfont termina de cargar y reemplaza la fuente de fallback, el texto suele recolocarse porque las métricas difieren. La solución es font-display: swap combinado con el descriptor CSS size-adjust en la regla @font-face, que escala el fallback para igualar las métricas de la webfont y elimina el salto visible.

Animaciones que afectan el layout. Una transición CSS sobre top, left, width o height dispara un reflow en cada frame. Anime transform y opacity en su lugar, ambos los maneja el navegador sin afectar el layout.

CLS es la más fácil de las tres de arreglar una vez que se encuentra el elemento culpable. La Layout Instability API en Chrome DevTools (panel Performance, luego pista “Web Vitals” o “Experience”) resalta cada cambio con el nodo del DOM afectado.

Datos de laboratorio versus datos de campo

Las dos formas de medir Core Web Vitals sirven a propósitos distintos. Confundirlas lleva a trabajo de optimización desperdiciado.

Los datos de laboratorio (lab) vienen de una prueba sintética. Lighthouse, la sección lab de PageSpeed Insights, WebPageTest, todos simulan una carga en un dispositivo controlado bajo una red controlada. El resultado es reproducible y útil para diagnóstico. Una puntuación lab de 95 en Lighthouse indica que la página puede ser rápida.

Los datos de campo (field) vienen de usuarios reales de Chrome. CrUX es el dataset público, actualizado cada mes. La sección field de PageSpeed Insights, la API de Chrome UX Report y el reporte de Core Web Vitals en Search Console leen de CrUX. Los datos de campo son lo que Google usa para evaluar su sitio para fines de ranking.

Una página puede sacar 100 en Lighthouse y fallar en CrUX. La discrepancia viene del mix de dispositivos y red de sus visitantes reales frente al perfil simulado. Lighthouse usa por defecto un Moto G4 sobre una conexión 4G lenta. Sus usuarios reales pueden estar en teléfonos Android más antiguos en redes más débiles, o en tabletas que ejecutan JavaScript más despacio de lo que asume el laboratorio.

El caso inverso también ocurre. Una página con puntuación Lighthouse de 60 puede pasar CrUX, porque los usuarios reales mayoritariamente visitan en dispositivos más rápidos que los que simula el lab.

Trate los datos lab como una herramienta de diagnóstico. Le dicen lo que un dispositivo optimizado debería ver, y producen stack traces, líneas de tiempo de render y comparativas claras antes y después. Trate los datos field como el veredicto. Le dicen lo que sus usuarios reales ven, y son los que determinan pasar o no el umbral de Core Web Vitals.

El ciclo es: cambiar la página, verificar en lab que el cambio funciona, y luego esperar 28 días a que CrUX refleje el cambio en los datos de campo.

El playbook para cada métrica

Cada métrica tiene un playbook recurrente. Leer datos de campo primero, diagnosticar en laboratorio, arreglar la causa raíz, verificar en laboratorio, y después esperar a que los datos de campo confirmen.

Playbook LCP.

1. Abrir PageSpeed Insights para la URL, mirar la sección de datos de campo.
2. Si la página falla LCP, bajar a los diagnósticos. El elemento más grande está nombrado.
3. Abrir el panel Performance de Chrome DevTools, recargar la página con throttling activado (Slow 4G, 4x CPU slowdown).
4. Encontrar el elemento LCP en la línea de tiempo. Mirar qué lo bloqueó. Responsables habituales en orden: respuesta del servidor, CSS bloqueante, JavaScript bloqueante, carga lenta de imagen.
5. Aplicar el arreglo más pequeño que ataque la causa dominante. Renderizado del lado del servidor para páginas SPA, formato moderno y dimensiones explícitas para LCP de imagen, async o defer para scripts bloqueantes.
6. Verificar en lab que LCP baje por debajo de 2,5 segundos.
7. Marcar la fecha. Los datos de campo reflejarán el cambio en CrUX 28 días después.

Playbook INP.

1. Abrir el reporte Core Web Vitals en Search Console. Encontrar URLs que fallan INP.
2. En un teléfono real o en la emulación móvil de DevTools, reproducir la interacción que falla.
3. Abrir el panel Performance, grabar desde antes del clic. Detener tras el siguiente paint.
4. Encontrar la tarea larga que bloqueó el main thread. El flame chart muestra el nombre de la función.
5. Aplicar uno de los arreglos estándar. Ceder con scheduler.yield. Diferir el trabajo detrás de requestIdleCallback. Moverlo a un Web Worker. Reemplazar el algoritmo síncrono por uno incremental.
6. Verificar en lab que la interacción complete por debajo de 200 ms.
7. Esperar la confirmación de CrUX en datos de campo.

Playbook CLS.

1. Abrir Chrome DevTools, panel Performance, grabar una carga de página con el overlay Web Vitals activado.
2. Cada cambio de diseño aparece como un rectángulo rojo sobre el elemento afectado con un puntaje de contribución.
3. Identificar la causa. Imagen sin dimensiones, anuncio insertado tarde, cambio de fuente, animación sobre propiedad de layout.
4. Aplicar el arreglo. Poner width y height en imágenes. Reservar espacio del contenedor para contenido dinámico. Usar font-display: swap con size-adjust. Animar transform en lugar de top.
5. Verificar que el cambio de diseño desaparezca en la grabación.
6. Esperar datos de campo.

El playbook funciona porque cada métrica tiene un conjunto pequeño y bien conocido de causas raíz. Una vez que sabe cuál está en juego, el arreglo es mecánico.

Cuándo mueven realmente el ranking las Core Web Vitals

La pregunta honesta que cada equipo termina haciendo. Llevamos años en el puesto diez, ¿pasarnos a verde en Core Web Vitals nos sube al cinco?

La respuesta honesta. Probablemente no por sí solo.

Google ha sido consistente en este punto. Core Web Vitals es un desempate, no un factor de ranking primario. Cuando dos páginas empatan en relevancia, calidad de contenido y autoridad, la que tenga mejores Core Web Vitals puede ganar el desempate. Cuando las páginas difieren en esas señales primarias, Core Web Vitals no cierra la brecha.

El impacto en ranking de Core Web Vitals se nota más claramente en tres escenarios.

Competencia en comercio móvil. Dos páginas de producto, relevancia similar, una carga en 2 segundos y la otra en 5. La rápida tiende a superar a la lenta con el tiempo, sobre todo en categorías muy competidas en las que cada señal cuenta.

Sitios cerca del límite. Un sitio cuyas Core Web Vitals están al borde del rango pobre y un grupo de páginas resbala al rango fallido, ese grupo pierde ranking. Mover las páginas que fallan de vuelta al verde restaura el ranking previo. El efecto es bidireccional y a veces brusco.

Señales de engagement vía comportamiento del usuario. Este es el efecto a largo plazo. Un sitio rápido y estable retiene a los usuarios más tiempo. Menor rebote, más páginas por sesión, mejor tasa de regreso. Esas señales de engagement correlacionan con ranking, y son a la vez una consecuencia de buenas Core Web Vitals.

Los escenarios en los que Core Web Vitals no mueve el ranking.

Un sitio sin autoridad temática. Un sitio nuevo puede ser el más rápido de su categoría y aún así rankear por debajo de sitios más viejos con peor rendimiento. La autoridad es la señal dominante hasta que se establece.

Una página con una clara brecha de contenido. Una página que no responde bien a la intención de búsqueda no rankea por encima de una que sí lo hace, sin importar la velocidad.

Temas en los que un sitio domina. Cuando un único sitio ha construido una autoridad clara en un nicho, los competidores más rápidos rara vez entran solo por velocidad. Necesitan profundidad de contenido y enlaces primero.

La regla práctica que se ha sostenido durante varios años: apunte al verde en Core Web Vitals porque mejora la experiencia del usuario, captura el desempate cuando la relevancia está cerca, y sostiene las señales de engagement que se acumulan con el tiempo. No apunte al verde como atajo de ranking, porque no lo es.

Para una visión más profunda de cómo la velocidad interactúa con el resto del SEO técnico, el checklist de auditoría SEO técnica cubre toda la superficie de problemas que se combinan con Core Web Vitals. Para tráfico que depende de motores de IA, el mismo trabajo de velocidad sostiene las páginas AI ready, porque tanto Google como los crawlers de IA prefieren un render rápido y estable.

Conclusión

Las Core Web Vitals son un conjunto pequeño de métricas que captura la mayor parte de lo que los usuarios reales sienten cuando una página es lenta. LCP para carga, INP para interactividad, CLS para estabilidad visual. Cada una tiene un umbral conocido, un conjunto conocido de causas raíz y una secuencia conocida de arreglos. Las herramientas lab le dicen si el arreglo funciona. Los datos field, el dataset CrUX rodante de 28 días, le dicen si los usuarios reales ven la mejora.

Deje de perseguir el 100 en Lighthouse. Apunte a datos field en verde. Las dos cosas son objetivos distintos, y la segunda es la que importa para usuarios y ranking.

Para el trabajo de auditoría que rodea a Core Web Vitals, combine esta guía con una revisión de meta tags y una rutina de crawler SEO regular. El trabajo de velocidad y el de crawl comparten causas raíz, recursos que bloquean render, tiempo de respuesta del servidor, assets sobredimensionados. Las dos auditorías corren juntas con más eficiencia que cualquiera por separado.

Si necesita una herramienta para crawlear su sitio y descubrir problemas de velocidad junto al resto del SEO técnico, descargue Seodisias gratis. Corre localmente en su máquina, no tiene límites de URL y reporta las señales a nivel de página que influyen en Core Web Vitals como parte de cada auditoría.