Core Web Vitals en 2026: umbrales, percentil 75 y cómo diagnosticarlos por orden

Yo les dedico tiempo por otro motivo: en Core Web Vitals puedes comprobar el efecto de un cambio en laboratorio en cuanto lo despliegas, sin esperar a que se mueva el ranking. Añades fetchpriority="high" a la imagen hero y el LCP de laboratorio te dice al momento si ha servido. El dato de campo tarda más: CrUX trabaja con los últimos 28 días, así que la mejora se va incorporando a medida que esa ventana se renueva.

Las tres métricas, los umbrales y el percentil 75

Google no evalúa la media: toma el percentil 75 del tráfico real de cada URL. Por definición, si más de una cuarta parte de tus visitas tiene una experiencia mala (por ejemplo, desde un móvil de gama media con mala red), la URL queda en Poor aunque el resto vaya perfecto. El usuario al que tienes que dejar contento es el del p75.

Consejo Cristofer: un error habitual en agencia es celebrar la mediana. Un ejemplo con cifras inventadas para ilustrarlo: una URL con un LCP mediano de 2,1 s y un p75 de 3,8 s está en "Needs Improvement", y el informe verde que has mandado al cliente no le sirve de nada. Mira siempre el p75 en Search Console, no la nota de un test de Lighthouse.

Datos de campo (CrUX) y datos de laboratorio (Lighthouse)

Cuando un cliente dice que su web "ya va rápida", lo primero es saber qué dato está mirando: si es de laboratorio o de campo.

CrUX (Chrome User Experience Report) recopila métricas anónimas de usuarios reales de Chrome durante los últimos 28 días, en una ventana que se va desplazando. Es el dataset que Google usa para ranking. Lighthouse hace un test simulado en condiciones controladas: Chrome headless, red 4G lenta limitada por throttling y un perfil de móvil de gama media.

Que los dos números no coincidan es normal. Lighthouse no ve los scripts de terceros que solo cargan después de aceptar cookies, ni tu hosting compartido con el tráfico de un martes a las 11:00, ni la mezcla de dispositivos y redes de tu audiencia.

Mi regla: Lighthouse para encontrar el problema, CrUX en Search Console para saber cómo te ve Google. Si discrepan, manda CrUX.

LCP · Largest Contentful Paint

LCP mide cuánto tarda en pintarse el elemento más grande visible en el primer pantallazo. Está muy ligada a la sensación de velocidad: el usuario da la web por cargada cuando ve ese elemento.

Cómo identificar tu elemento LCP real

Antes de optimizar nada, averigua qué elemento es. Hay tres formas:

• PageSpeed Insights lo indica en el bloque Largest Contentful Paint element.
• Chrome DevTools → Performance: graba la carga, busca el marcador LCP en la timeline y te lleva al nodo del DOM.
• Extensión Web Vitals para Chrome: muestra el LCP en tiempo real mientras navegas, sin grabar.

En la mayoría de webs es la imagen hero. Si no hay una imagen prominente, puede ser un bloque de texto largo, y si el hero es un vídeo en autoplay, el comportamiento cambia.

Cinco causas habituales y cómo comprobarlas

No hay una cifra universal de cuánto suma cada causa: depende del resto de la página. Lo que sí puedes hacer es ver cuánto pesa en la tuya. PageSpeed Insights desglosa el LCP en cuatro fases (TTFB, retraso de carga, tiempo de carga y retraso de renderizado), y cada causa cae en una de ellas.

El TTFB es el suelo: el LCP nunca puede ser más rápido que la respuesta del servidor. El lazy loading en el hero tiene la particularidad de que es una buena práctica aplicada al elemento equivocado.

Qué arreglar primero

El orden en el que yo lo abordo:

1. Imágenes en WebP o AVIF. Según el estudio de Google sobre WebP, a calidad equivalente pesa entre un 25 y un 34 % menos que un JPEG. AVIF suele comprimir todavía más, pero depende de la imagen.
2. fetchpriority="high" + preload en la imagen hero, para que el navegador sepa qué descargar primero.
3. Hosting con TTFB < 300 ms: un WordPress gestionado decente, o estático en Vercel, Netlify o Cloudflare Pages.
4. CDN delante. Cloudflare, incluso en plan gratuito, acerca los estáticos a usuarios que están lejos de tu servidor.
5. Fuentes críticas servidas en local y con preload, con font-display: swap u optional (más abajo explico por qué yo uso optional).

Lo que no funciona: comprar un plugin de caché de pago para un problema que está en el hosting. La caché no acelera un servidor que tarda 800 ms en devolver el primer byte.

INP · Interaction to Next Paint

INP sustituyó oficialmente a FID en marzo de 2024 y es bastante más exigente.

Por qué INP es más exigente que FID

FID medía solo el retraso de la primera interacción. INP mide la latencia de todas las interacciones de la sesión y reporta la peor, o casi la peor en páginas con muchas interacciones.

Supón que tu web tarda 350 ms en responder al clic en el menú móvil. FID no lo registraba salvo que ese clic fuera el primero de la sesión. INP lo registra cada vez, así que un script lento en una interacción frecuente empeora el INP aunque la carga inicial vaya bien.

JavaScript en el main thread y otros culpables típicos

Los sospechosos habituales. Cuánto bloquea cada uno depende de la versión del script, de cómo se cargue y del dispositivo; para verlo en tu web, la auditoría "Reduce el impacto del código de terceros" de Lighthouse muestra el tiempo de bloqueo del main thread por proveedor:

• Chats de terceros (Tawk.to, Crisp, Intercom) cargando en la home.
• Píxeles de tracking (Meta, TikTok, LinkedIn Insight).
• Heatmaps (Hotjar, Microsoft Clarity).
• Themes de WordPress que cargan mucho JavaScript antes del render (Divi, Avada, BeTheme y similares).
• Hidratación de SPAs pesadas en React o Vue.
• Event listeners sin debounce en scroll o mousemove.

Para localizarlo: Chrome DevTools → Performance → graba la interacción → busca long tasks de más de 50 ms en el main thread.

Cómo optimizar INP sin cambiar de framework

Una recomendación que se oye mucho es migrar a Astro o a Qwik. Es cara y muchas veces innecesaria. Antes de plantearla, prueba esto:

1. Audita los scripts de terceros y quita los que nadie usa.
2. async o defer en todo lo que no sea crítico para el render.
3. Web Workers para tareas pesadas de parsing o cálculo.
4. Debounce en los event listeners de alta frecuencia.
5. Code splitting con dynamic imports.
6. En React 18+, useDeferredValue y startTransition para interacciones sobre listas grandes.

Un ejemplo hipotético, para que veas el orden de las cosas: si una web WordPress tiene un INP de 380 ms y el grueso del trabajo en main thread lo generan tres scripts de tracking que nadie consulta, quitarlos y cargar el resto con async puede ser suficiente para bajar de 200 ms sin tocar el código del producto. Compruébalo con una grabación en DevTools antes y después.

Consejo Cristofer: antes de proponer una migración de framework, abre Chrome DevTools → Network, filtra por "script" y ordena por tamaño. Es lo primero que reviso cuando me llega un INP malo.

¿Search Console en rojo desde hace meses? Auditoría técnica con foco en Core Web Vitals: qué tocar primero para salir de "Poor" y qué no merece la pena tocar.

CLS · Cumulative Layout Shift

CLS mide cuánto se desplaza el contenido de forma inesperada. Cada desplazamiento se puntúa multiplicando la impact fraction por la distance fraction; los desplazamientos se suman dentro de ventanas de sesión y Google toma la peor ventana.

El caso que todos conocemos: vas a pulsar un botón, aparece un banner que lo empuja hacia abajo y acabas haciendo clic en otra cosa.

Sus causas suelen estar más acotadas que las de LCP o INP. Estas son cuatro habituales.

Cuatro causas habituales

Estas correcciones valen para cualquier CMS. Lo que cambia es dónde suelo encontrar el problema. En WordPress, lo primero que miro es el banner de cookies, porque muchas veces basta con sacarlo del flujo del documento con CSS. En Shopify, suele ser el theme cuando se le añaden bloques promocionales. En Next.js, el componente <Image> obliga a declarar dimensiones y evita el problema de raíz.

Cómo diagnosticar tus Core Web Vitals, paso a paso

Estos son los pasos que sigo: empiezo por los datos de campo de Search Console y bajo hasta la URL concreta.

1. Search Console → Experiencia → Core Web Vitals. Localiza los grupos de URLs en Poor y en Needs Improvement. Google ya las agrupa por patrón de problema.
2. Una URL representativa de cada grupo en PageSpeed Insights. Primero móvil.
3. Sección Diagnósticos: apunta solo los tres primeros ítems por impacto estimado. El resto, en otra pasada.
4. Chrome DevTools → Performance: graba la carga completa y localiza las long tasks.
5. Extensión Web Vitals activa: navega la página e interactúa para ver LCP, INP y CLS en tiempo real.

El resultado es una lista corta de acciones para cada grupo de URLs, en vez de una lista de cuarenta. El tiempo depende del sitio: en una web con pocas plantillas es una sesión corta; en un eCommerce con muchos grupos de URLs, hay que repetirlo por grupo.

Cuando Lighthouse dice verde y CrUX dice rojo

Tres causas típicas y qué hacer con cada una:

• Hosting irregular. PageSpeed Insights lanza Lighthouse desde servidores de Google; tus usuarios llegan a tu hosting compartido con tráfico real. Prueba con WebPageTest desde la región de tu audiencia.
• Scripts que cargan tras el consentimiento. Lighthouse no acepta cookies y tus usuarios sí. Lanza Lighthouse a mano desde DevTools después de aceptar el banner.
• Dispositivos y redes peores que la simulación. Activa en DevTools un throttling más agresivo y reduce la CPU.

Lighthouse te dice dónde mirar; el dato que cuenta para Google es el de CrUX.

Consejo Cristofer: cuando el cliente celebra su 95/95 de Lighthouse y Search Console sigue en rojo, explícale la diferencia antes de que tenga que explicarla él a su dirección. Lleva a la reunión un pantallazo de PageSpeed con los datos de CrUX y los de laboratorio de la misma URL, uno al lado del otro. Así ve las dos cifras en la misma pantalla y puedes explicarle de dónde sale cada una.

¿Importan los Core Web Vitals a las IAs?

Directamente, no. GPTBot, ClaudeBot, PerplexityBot o CCBot descargan el HTML sin renderizarlo: no miden LCP porque no pintan nada, ni INP porque no interactúan.

La influencia llega por Google. AI Overviews se muestra dentro de la SERP, y las páginas que cita salen de los sistemas de ranking de Google, de los que forman parte las señales de Page Experience. Una web en rojo no queda excluida, pero compite en peores condiciones. Además, un LCP lento o un CLS alto empeoran la experiencia, y eso se traslada a cómo interactúan los usuarios con la página.

Si tu tráfico empieza a llegar desde ChatGPT, eso no es motivo para dejar de cuidar los Core Web Vitals: siguen pesando en Google, y Google sigue alimentando AI Overviews.

Caso real: cristofercruz.net

En la captura de abajo está el informe de PageSpeed Insights de la home, con la fecha, el dispositivo y la versión de Lighthouse: 100/99/100/100 en rendimiento, accesibilidad, prácticas recomendadas y SEO. Es una puntuación de laboratorio, no un dato de campo.

Cómo está montada:

• HTML plano, sin hidratación: no hace falta JavaScript para ver el contenido.
• Fuentes en local, con preload de las dos variantes críticas y font-display: optional.
• Todas las imágenes en WebP, con width y height explícitos y fetchpriority="high" en el hero.
• CSS crítico inline y el resto diferido.
• Un único script, el de analítica, cargado con defer.
• Cloudflare como CDN, con caché agresiva sobre los estáticos.

La configuración de las fuentes no fue la inicial. Empecé con font-display: swap, que es lo que suele recomendarse, y la cambié a optional. La puntuación de la captura está medida ya con optional.

La diferencia entre las dos: con swap, el navegador pinta el texto con la fuente de sistema y lo vuelve a pintar cuando llega la fuente web. Ese segundo pintado puede retrasar el LCP si el elemento LCP es texto, y mover el contenido si las dos fuentes no miden igual. Con optional, si la fuente no llega en un margen muy corto, el navegador se queda con la de sistema en esa vista y no hay cambio. Como la fuente está en local y precargada, casi siempre llega a tiempo.

El coste es que, en alguna primera visita con mala conexión, se verá la fuente de sistema. En mi web lo acepto. En una marca donde la tipografía es innegociable, swap con size-adjust puede ser mejor opción.

Si quieres probarlo en tu web, cambia solo esa línea y compara la misma URL antes y después con varias ejecuciones de PageSpeed Insights, porque la puntuación de Lighthouse varía de una ejecución a otra. Y confirma el resultado en CrUX pasadas unas semanas.

Preguntas frecuentes

Referencias

Documentación oficial para consultar las métricas, sus umbrales y las técnicas de diagnóstico y optimización.

1. Web Vitals: métricas, umbrales y percentil 75 web.dev · Google
2. Core Web Vitals y resultados de búsqueda Google Search Central
3. Chrome UX Report (CrUX) Chrome for Developers
4. Diferencias entre datos de campo y de laboratorio web.dev · Google
5. Optimización de Largest Contentful Paint (LCP) web.dev · Google
6. Optimización de Interaction to Next Paint (INP) web.dev · Google
7. Optimización de Cumulative Layout Shift (CLS) web.dev · Google