Core Web Vitals en 2026: LCP, CLS e INP explicados sin humo
LCP, CLS e INP explicados con umbrales reales, por qué INP sustituyó a FID en 2024, cómo se miden de verdad (CrUX, no Lighthouse) y por qué le pesan más a un medio digital con mucha publicidad que a una landing estática.
Respuesta rápida: los Core Web Vitals son tres métricas — LCP, CLS e INP — que miden la experiencia real de carga, estabilidad e interactividad de una página, calculadas sobre datos reales de usuarios de Chrome (CrUX), no sobre una simulación de laboratorio. Su peso directo en el ranking es modesto, pero condicionan señales de comportamiento (rebote, long clicks) que sí importan. Y en sitios con mucha publicidad de terceros — la mayoría de medios digitales — son la causa número uno de reprobar el informe.
- Los tres umbrales "Bueno" en el percentil 75 de las visitas: LCP ≤ 2,5 s, CLS ≤ 0,1, INP ≤ 200 ms.
- INP sustituyó a FID en marzo de 2024 porque mide la peor interacción de toda la visita, no solo la primera.
- Google mide con CrUX (datos reales de Chrome), no con Lighthouse (simulación de laboratorio). Son números distintos y responden a preguntas distintas.
- El efecto en ranking es indirecto: pesa poco como factor directo, pero condiciona el comportamiento del usuario, y ese comportamiento sí alimenta sistemas como NavBoost.
- En medios digitales y sitios con muchas redes publicitarias, la causa habitual de reprobar no es el contenido editorial: es el JavaScript de terceros que cargan los propios anuncios.
1. Qué mide cada métrica
Los Core Web Vitals no son una puntuación abstracta de "velocidad": son tres mediciones concretas de tres momentos distintos de la visita.
| Métrica | Qué mide | Umbral "Bueno" | Umbral "Deficiente" |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Tiempo hasta que se renderiza el elemento más grande del viewport (hero image, titular, vídeo principal) | ≤ 2,5 s | > 4 s |
| CLS (Cumulative Layout Shift) | Cuánto se mueven los elementos visuales de forma inesperada mientras carga la página | ≤ 0,1 | > 0,25 |
| INP (Interaction to Next Paint) | Latencia de la peor interacción del usuario durante toda la sesión — clic, tap, tecla | ≤ 200 ms | > 500 ms |
La columna que suele faltar en los resúmenes rápidos es "durante toda la sesión" en INP. No es un dato menor: es el motivo por el que esta métrica sustituyó a la anterior.
2. Por qué INP sustituyó a FID en 2024
Antes de marzo de 2024, la tercera pata de los Core Web Vitals era FID (First Input Delay): el retraso entre la primera interacción del usuario y el momento en que el navegador empieza a procesarla. El problema de FID no era que midiera mal, era que medía poco: solo capturaba el primer clic, que en la mayoría de páginas ocurre cuando todavía hay poco JavaScript compitiendo por el hilo principal.
INP mide la interacción más lenta de toda la visita, desde que el usuario hace clic hasta que el navegador pinta el siguiente frame visual. Eso incluye el menú que no responde a la tercera vez que se abre, el filtro de una tabla que se traba después de que hayan cargado los anuncios, o el botón de "enviar" de un formulario que tarda en reaccionar porque un script de analítica de terceros acaba de despertar. Es exactamente el tipo de fricción que un usuario recuerda y que un test de laboratorio de una sola carga no detecta.
3. Por qué le pesan más a un medio digital que a una landing
Esta es la pregunta que casi ningún artículo en español responde con honestidad: ¿por qué mi web de contenido reprueba Core Web Vitals si el texto en sí no pesa nada?
La respuesta casi siempre es la misma: no es el contenido, es el ecosistema publicitario que lo rodea.
- CLS se dispara cuando un anuncio programático reserva menos espacio del que ocupa su creatividad final, y el contenido salta hacia abajo cuando el anuncio termina de cargar — normalmente varios segundos después del primer render.
- INP se dispara cuando media docena de scripts de terceros (red publicitaria, gestor de consentimiento, analítica, red social, chat) compiten por el hilo principal justo en el momento en que el lector intenta interactuar — hacer scroll, tocar un enlace, cerrar un banner.
- LCP se dispara cuando la imagen o el vídeo principal compite por ancho de banda con los mismos scripts, o cuando el gestor de consentimiento bloquea el render hasta que el usuario decide.
Una landing de servicios con cero scripts de terceros rara vez reprueba estas tres métricas. Un medio digital con 6-8 redes publicitarias, un CMP de consentimiento y dos o tres píxeles de analítica parte con una desventaja estructural, y optimizar el propio contenido editorial no arregla el problema si la causa real vive en el ad stack.
4. Cómo se miden de verdad: CrUX, no Lighthouse
Aquí está la confusión más extendida: Lighthouse y PageSpeed Insights no miden lo mismo que Search Console.
Lighthouse simula una única carga de página, con un dispositivo y una conexión fijos, en condiciones de laboratorio controladas. Es determinista y reproducible, lo cual lo hace excelente para depurar un cambio concreto — pero no representa lo que experimentan los usuarios reales.
CrUX (Chrome User Experience Report) agrega telemetría anónima de usuarios reales de Chrome que visitaron la página, sobre el percentil 75 de esas visitas. Es lo que Google usa realmente para evaluar la experiencia y lo que se muestra en el informe de Core Web Vitals de Search Console. Una web puede sacar 95-100 en Lighthouse local y reprobar en CrUX si su tráfico real llega mayoritariamente desde móviles de gama media-baja con redes 4G congestionadas — un patrón habitual en tráfico de búsqueda en español fuera de las grandes capitales.
La consecuencia práctica: si vas a diagnosticar un problema, usa Lighthouse. Si vas a evaluar si tu web pasa o no pasa, usa el informe de Core Web Vitals de Search Console, que se alimenta de CrUX.
5. Diagnóstico en la práctica
Tres pasos, en orden, antes de tocar código:
- Search Console → Core Web Vitals. Confirma qué URLs reprueban y en qué métrica concreta — no asumas que todo el sitio tiene el mismo problema. Un blog y una ficha de producto del mismo dominio pueden reprobar métricas distintas por razones distintas.
- PageSpeed Insights sobre una URL reprobada. Te da el dato de campo (CrUX, si hay suficiente tráfico) y el de laboratorio (Lighthouse) en la misma pantalla, además del desglose de qué recurso concreto contribuye a cada métrica.
- Chrome DevTools → pestaña Performance, con "throttling" activado. Para ver en directo qué script bloquea el hilo principal cuando simulas una interacción — el paso que confirma si la causa es un anuncio, un gestor de consentimiento o código propio.
Errores comunes
- Optimizar solo con Lighthouse y dar el problema por resuelto sin comprobar CrUX en Search Console semanas después.
- Culpar al contenido editorial (imágenes, vídeo) cuando el causante real es un script de terceros del stack publicitario.
- Medir INP con una sola interacción de prueba en vez de revisar el percentil 75 de interacciones reales.
- Añadir más scripts de monitorización de rendimiento para "vigilar" el problema, empeorando el propio INP que se quería medir.
- Tratar los Core Web Vitals como un factor de ranking directo grande, cuando su influencia real es indirecta a través del comportamiento del usuario.
Preguntas frecuentes
Las tres métricas que componen los Core Web Vitals. LCP (Largest Contentful Paint) mide cuánto tarda en pintarse el elemento principal del viewport. CLS (Cumulative Layout Shift) mide cuánto se mueven los elementos visuales de forma inesperada durante la carga. INP (Interaction to Next Paint) mide la latencia de la peor interacción del usuario durante toda la visita, no solo la primera.
Sí, en marzo de 2024. FID (First Input Delay) solo medía el retraso de la primera interacción, que en la práctica suele ser rápida porque el usuario aún no ha empezado a usar la página en serio. INP mide la peor interacción de toda la sesión — un menú que no responde al tercer clic, un formulario que se traba al enviarlo — que es donde de verdad se nota una web lenta.
Su peso directo como factor de ranking es modesto, y Google lo ha repetido varias veces. Lo que sí es real es el efecto indirecto: una web con INP alto genera más rebote y menos long clicks, y esas señales de comportamiento sí alimentan sistemas de ranking como NavBoost. El impacto no es la métrica en sí, es lo que la métrica dice sobre la experiencia real.
Porque la publicidad programática es la causa más común de mal CLS (anuncios que cargan tarde y empujan el contenido) y de mal INP (scripts de terceros que bloquean el hilo principal justo cuando el lector intenta interactuar). Un medio con 6-8 redes de anuncios cargando simultáneamente tiene una probabilidad mucho mayor de reprobar INP que una landing con cero JavaScript de terceros — no por el contenido editorial, sino por el ecosistema publicitario que lo rodea.
Con datos reales — el CrUX (Chrome User Experience Report), que agrega la telemetría anónima de usuarios reales de Chrome sobre el percentil 75 de las visitas. Lighthouse es una simulación de laboratorio en una sola carga con una conexión y un dispositivo fijos: útil para depurar, pero no es lo que Google usa para evaluar la experiencia real de tu web. Una web puede sacar 100 en Lighthouse y reprobar en CrUX si sus usuarios reales navegan desde móviles de gama baja con conexión 4G irregular.
LCP igual o menor a 2,5 segundos, CLS igual o menor a 0,1, e INP igual o menor a 200 milisegundos, los tres medidos en el percentil 75 de las visitas, tanto en móvil como en escritorio. Un sitio pasa el informe de Search Console cuando las tres métricas están en 'Bueno' de forma simultánea — basta con que una sola falle en el percentil 75 para que el informe marque la URL como 'Necesita mejora' o 'Deficiente'.
¿Sabes si tu web reprueba Core Web Vitals en datos reales, no en Lighthouse?
Auditamos tu informe de CrUX en Search Console, aislamos qué script o qué red publicitaria concreta está inflando tu INP o tu CLS, y te decimos qué mover primero. Con evidencia de tus propios datos, no con una captura de Lighthouse en local.
Ver cómo auditamos rendimiento técnicoFOUNDER & SEO LEAD
Founder de Autoridad Digital. Especialista en SEO, Generative Engine Optimization, Topical Authority y Authority Stacking, PR Digital. Todos los artículos del blog están firmados por él.
¿Te resulta útil este contenido? Añadinos como fuente preferida en Google.
Activa las cookies de terceros (Google) para ver este botón.