Casi todos los artículos sobre Core Web Vitals te dan lo mismo: los tres umbrales, una lista de causas comunes y cuatro quick wins. Ninguno responde a la pregunta que de verdad te haces cuando abres Search Console y lo ves en rojo: cómo diagnostico qué está fallando en mi web y en qué orden lo arreglo.
Este post es eso: un protocolo. Más el escenario que nadie explica bien (Lighthouse verde, CrUX rojo) y el ángulo que en 2026 ya no se puede ignorar: qué papel juegan los Core Web Vitals cuando el que te lee no es Google, sino una IA.
Qué son los Core Web Vitals en 2026 (y por qué siguen mandando)
Los Core Web Vitals son las tres métricas oficiales con las que Google mide la experiencia real de tu usuario: LCP (velocidad de carga percibida), INP (respuesta a la interacción) y CLS (estabilidad visual). Son señal de ranking desde el Page Experience update de 2021.
Pero la razón para prestarles atención en 2026 no es esa. Es que son la única capa de SEO técnico donde el ROI se mide en horas, no en meses. Un cambio de arquitectura de contenidos tarda un trimestre en verse. Un fetchpriority="high" en la imagen hero se nota en el siguiente crawl.
Las tres métricas, los umbrales y el percentil 75
| Métrica | Qué mide | Bueno | Mejorable | Malo |
|---|---|---|---|---|
| LCP | Tiempo hasta pintar el elemento más grande del viewport | < 2,5 s | 2,5 – 4 s | > 4 s |
| INP | Latencia de respuesta a las interacciones del usuario | < 200 ms | 200 – 500 ms | > 500 ms |
| CLS | Movimiento visual inesperado durante la carga | < 0,1 | 0,1 – 0,25 | > 0,25 |
Y aquí el detalle que medio SERP menciona pero nadie explica: Google no evalúa la media, evalúa el percentil 75 del tráfico real de tu web. Traducido: si el 30 % de tus usuarios entra desde un móvil de gama media con red lenta y tiene una experiencia mala, tu URL es Poor aunque el 70 % restante vaya perfecto.
No optimices para el usuario medio. Optimiza para el usuario del p75.
Consejo Cristofer: el error más común de agencia es celebrar un LCP mediano de 2,1 s. Si el p75 es 3,8 s, Google te clasifica en "Needs Improvement" y ese informe verde que has mandado al cliente no significa nada. Mide siempre el p75 en Search Console, no la mediana en Lighthouse.
Datos de campo (CrUX) vs datos de laboratorio (Lighthouse): por qué no son lo mismo
Esta distinción es la que más malentendidos genera en reuniones con cliente.
CrUX (Chrome User Experience Report) recopila métricas anónimas de usuarios reales de Chrome en una ventana móvil de 28 días. Es el dataset que Google usa para ranking. Lighthouse simula un test en condiciones controladas: Chrome headless, throttling de red 4G, perfil de dispositivo tipo Moto G4.
Los dos números pueden diferir muchísimo, y por buenas razones. Lighthouse no ve los scripts de terceros que solo cargan tras aceptar cookies. No ve tu hosting compartido bajo tráfico real de un martes a las 11:00. No reproduce la variabilidad de dispositivos y redes de tu audiencia concreta.
La regla operativa es simple: para debugging usa Lighthouse; para ranking, CrUX en Search Console. Si discrepan, gana CrUX.
LCP · Largest Contentful Paint
LCP mide cuánto tarda en pintarse el elemento más grande visible en el above-the-fold. Es la métrica más decisiva para la percepción de velocidad —el usuario decide que tu web "ya cargó" cuando ve ese elemento— y la que mejor ROI da al optimizar.
Cómo identificar tu elemento LCP real
No optimices a ciegas. Primero identifica qué elemento es. Tres formas:
- PageSpeed Insights lo indica explícitamente en el bloque Largest Contentful Paint element.
- Chrome DevTools → Performance: graba la carga y busca el marcador LCP en la timeline; te da la referencia al nodo del DOM.
- Extensión Web Vitals para Chrome: te muestra el LCP en tiempo real mientras navegas, sin grabar nada.
En la mayoría de webs el LCP es la imagen hero. Pero puede ser un bloque de texto largo si no hay imagen prominente, o comportarse de forma extraña si el hero es un vídeo en autoplay.
Las 5 causas más comunes con impacto medido en segundos
Estos son los rangos que veo repetirse en auditorías, alineados con los benchmarks de web.dev:
- Hosting con TTFB > 600 ms → suma 1-2 segundos al LCP. Es el techo invisible: por debajo de él no puedes bajar.
- Imagen hero sin optimizar (JPG de más de 500 KB) → 1-3 segundos.
- CSS y JS render-blocking en el
<head>→ 200-800 ms por recurso. - Fuentes web sin
font-display: swap→ 200-500 ms de texto bloqueado. - Lazy loading mal aplicado (
loading="lazy"en la imagen hero) → 500 ms a 1 segundo de retraso completamente innecesario.
Esa quinta causa es la más frustrante de todas, porque es autoinfligida por una buena práctica aplicada en el sitio equivocado.
Optimización priorizada por ROI
Cinco fixes que dan el 80 % de la mejora, en orden:
- Migrar imágenes a WebP o AVIF — reducción de peso del 30 al 65 % sin pérdida perceptible.
fetchpriority="high"+preloaden la imagen del hero — le dices al navegador qué es importante en lugar de dejarle adivinar.- Hosting con TTFB < 300 ms — managed WordPress decente, o estático en Vercel/Netlify/Cloudflare Pages.
- CDN delante — Cloudflare en plan gratuito ya te resuelve gran parte del problema geográfico.
font-display: swap+ preload de las fuentes críticas, servidas en local.
El anti-patrón clásico: comprar un plugin de caché de pago esperando que arregle un problema que está en el hosting. La caché no puede acelerar un servidor que tarda 800 ms en responder al primer byte.
INP · Interaction to Next Paint
INP es la métrica que más webs está suspendiendo. Reemplazó oficialmente a FID en marzo de 2024 y es sustancialmente más exigente.
Por qué INP es más exigente que el FID al que reemplazó
FID medía una sola cosa: el retraso de la primera interacción. INP mide la latencia de todas las interacciones a lo largo de la sesión y reporta prácticamente la peor.
Ejemplo concreto: si tu web tarda 350 ms en responder al clic en el menú móvil, FID no lo detectaba salvo que ese clic fuera casualmente el primero de la sesión. INP lo detecta cada vez que ocurre. Ya no hay dónde esconder el JavaScript basura.
El resultado se ve en los datos agregados: en móvil, INP es hoy el cuello de botella dominante, con una proporción de sitios en rojo bastante mayor que en LCP o CLS.
JavaScript en el main thread y otros culpables típicos
Los sospechosos habituales, con el coste aproximado en main thread:
- Chats de terceros (Tawk.to, Crisp, Intercom) cargando en home: 150-300 ms cada uno.
- Pixels de tracking (Meta, TikTok, LinkedIn Insight): 100-250 ms.
- Heatmaps (Hotjar, Microsoft Clarity): 200-400 ms.
- Hidratación de SPAs pesadas en React o Vue.
- Event listeners sin debounce en
scrollomousemove. - Themes de WordPress con 200-500 KB de JS antes del render (Divi, Avada, BeTheme y compañía).
El diagnóstico es siempre el mismo: 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
Antes de nada, una advertencia: la recomendación que más circula —"migra a Astro o a Qwik"— es cara y muchas veces innecesaria. Antes de plantear una migración, aplica esto:
- Auditar third-party scripts y eliminar los que nadie usa activamente.
asyncodeferen todo lo que no sea crítico para el render.- Web Workers para tareas pesadas de parsing o cálculo.
- Debouncing en event listeners de alta frecuencia.
- Code splitting con dynamic imports.
- En React 18+,
useDeferredValueystartTransitionpara interacciones sobre listas grandes.
Un caso típico: una web WordPress pasa de INP 380 ms a INP 180 ms simplemente eliminando tres scripts de tracking que nadie consultaba y añadiendo async al resto. Cero líneas de código de producto tocadas.
Consejo Cristofer: antes de proponer una migración de framework, audita los third-party con Chrome DevTools → Network → filtro "script" y ordena por tamaño. En torno al 70 % de los casos de INP malo se resuelve eliminando 3-5 scripts que ya nadie usa.
Auditoría técnica con foco en Core Web Vitals.
Diagnóstico priorizado por impacto real: qué tocar primero para salir de "Poor" en el siguiente ciclo de CrUX, y qué no vale la pena tocar.
CLS · Cumulative Layout Shift
CLS mide el movimiento visual inesperado durante la carga. La fórmula multiplica impact fraction por distance fraction de cada desplazamiento y los acumula.
El ejemplo cotidiano lo has vivido: vas a pulsar un botón y de repente aparece un banner que lo empuja 100 px hacia abajo, y acabas haciendo clic en otra cosa. Eso es CLS.
Es la métrica más fácil de arreglar del trío. Casi siempre son cuatro correcciones concretas.
Las 4 causas del 90 % de los casos
- Imágenes sin
widthyheightexplícitos → añade las dimensiones en el HTML y deja que CSS las escale. - Ads e iframes sin espacio reservado → contenedor con
aspect-ratioomin-height. - Fuentes web que cambian de tamaño al hacer swap (FOIT/FOUT) →
size-adjustyascent-overrideen el@font-face. - Contenido inyectado por encima del existente —el banner de cookies clásico— →
position: fixeden lugar de meterlo en el flujo del documento.
Correcciones que funcionan en cualquier CMS
Prácticas universales, independientes del stack: aspect-ratio en todos los contenedores de media, position: fixed en el banner de cookies, dimensiones explícitas obligatorias en cada <img>, y min-height en los contenedores de publicidad.
Por plataforma: en WordPress, la mitad de los problemas de CLS vienen del banner de cookies y se resuelven con tres líneas de CSS. En Shopify, suele venir del theme cuando se le añaden bloques promocionales. En Next.js, el componente <Image> nativo ya fuerza dimensiones y te ahorra el problema de raíz.
Cómo diagnosticar tus Core Web Vitals en 15 minutos
Esto no es una lista de herramientas. Es un flujo de trabajo con orden.
Protocolo con Search Console, PageSpeed y DevTools
- Search Console → Experiencia → Core Web Vitals. Identifica los grupos de URLs en Poor y Needs Improvement. Google ya te las agrupa por patrón de problema: aprovéchalo.
- Toma una URL representativa de cada grupo y pásala por PageSpeed Insights. Móvil primero, siempre.
- Lee la sección Diagnósticos y anota solo los tres primeros ítems por impacto potencial estimado. Ignora el resto en esta pasada.
- Abre la URL en Chrome → DevTools → Performance, graba la carga completa e identifica las long tasks.
- Navega la página con la extensión Web Vitals activa para ver LCP, INP y CLS en tiempo real mientras interactúas.
En 15 minutos tienes las tres acciones con más ROI para ese grupo de URLs. No una lista de cuarenta.
Cuando Lighthouse dice verde y CrUX dice rojo: qué hacer
El escenario más frustrante en producción. Tres causas típicas, con su solución:
- Hosting inconsistente. Lighthouse corre desde infraestructura de Google; tu hosting compartido con tráfico real, no. → Prueba con WebPageTest desde tu región real, no desde el datacenter más cercano a Google.
- Scripts que solo cargan tras el consentimiento de cookies. Lighthouse no acepta cookies; tus usuarios sí. → Haz un run manual de Lighthouse aceptando el banner antes de medir.
- Dispositivos y redes reales peores que la simulación. → Activa throttling agresivo en DevTools y mide con perfil de CPU reducido.
Y la regla que cierra la discusión: si CrUX dice rojo, es rojo. Lighthouse es una herramienta de diagnóstico, no un veredicto.
Consejo Cristofer: cuando el cliente celebra su 95/95 de Lighthouse pero Search Console sigue en rojo, tienes que explicarle esta diferencia antes de que la explique él a su dirección. Lleva a la reunión un pantallazo de PageSpeed con CrUX y Lab en la misma URL, uno al lado del otro. Se entiende en cinco segundos.
Core Web Vitals más allá de Google: ¿importan a las IAs?
Respuesta directa: los crawlers de IA no evalúan Core Web Vitals. GPTBot, ClaudeBot, PerplexityBot, Google-Extended y CCBot no son navegadores, son fetchers de HTML. No miden LCP porque no pintan nada, y no miden INP porque no interactúan con nada.
Pero de ahí no se sigue que los CWV sean irrelevantes para GEO/AEO. Hay dos vías indirectas:
- AI Overviews se sirve dentro de la SERP de Google, y los sitios que cita se seleccionan con el aparato de señales de Google, Page Experience incluido. Una web en rojo tiene menos papeletas.
- LCP y CLS afectan a bounce rate y dwell time. Esas señales de comportamiento sí las mide Google, y sí influyen en qué páginas considera lo bastante buenas para citar.
Traducción operativa: los Core Web Vitals no son un factor directo para las IAs, pero sí un factor indirecto vía Google. No los desatiendas con la excusa de que tu tráfico ahora viene de ChatGPT.
Caso real: cómo alcanzamos 100/99/100/100 en cristofercruz.net
Este site saca 100/99/100/100 en PageSpeed de forma sostenida, no en un test afortunado. El stack es deliberadamente aburrido: HTML estático servido con PHP en Hostinger, con Cloudflare delante.
Las decisiones concretas:
- HTML plano, sin framework y sin hidratación. Cero JavaScript necesario para ver el contenido.
- Fuentes servidas en local, con
font-display: swapy preload de las dos variantes críticas. - Todas las imágenes en WebP, con
widthyheightexplícitos yfetchpriority="high"en el hero. - CSS crítico inline, el resto diferido.
- Cero third-party scripts en el body. Un único script de analítica, con
defer. - Cloudflare como CDN con caché agresiva sobre los estáticos.
La moraleja: los 100/99/100/100 no salen de un plugin. Salen de decisiones de arquitectura tomadas antes de escribir la primera línea de CSS.
Preguntas frecuentes
¿Cuáles son los umbrales de Core Web Vitals en 2026?
LCP por debajo de 2,5 segundos, INP por debajo de 200 milisegundos y CLS por debajo de 0,1 se consideran buenos. Se pasa a "malo" con LCP superior a 4 segundos, INP superior a 500 ms y CLS superior a 0,25. Google evalúa el percentil 75 del tráfico real de la URL, no la media.
¿Por qué mi Lighthouse dice verde y Search Console dice rojo?
Porque miden cosas distintas: Lighthouse es un test simulado en condiciones controladas y Search Console usa datos de campo de usuarios reales (CrUX) de los últimos 28 días. Las causas habituales de la discrepancia son el hosting bajo tráfico real, los scripts que solo cargan tras aceptar cookies y los dispositivos reales de tu audiencia. Si CrUX dice rojo, es rojo.
¿Cómo se optimiza INP en un sitio WordPress?
Empieza auditando los third-party scripts en DevTools → Network y elimina los que nadie usa: chats, pixels y heatmaps son los principales culpables. Después añade async o defer a todo lo no crítico y revisa si el theme carga cientos de kilobytes de JavaScript antes del render. En la mayoría de casos no hace falta cambiar de framework ni de theme.
¿Cuánto pesan los Core Web Vitals en el ranking real?
Son una señal real pero de segundo orden: no compensan un contenido que no responde a la intención de búsqueda. Su peso se nota sobre todo en SERPs competidas donde la relevancia está empatada, y en el efecto indirecto sobre conversión y comportamiento del usuario. Como criterio práctico: no ganan un ranking, pero sí lo pueden perder.
¿Los Core Web Vitals influyen en AI Overviews y ChatGPT?
Los crawlers de IA no miden Core Web Vitals, porque hacen fetch del HTML sin renderizar ni interactuar. Pero AI Overviews selecciona las páginas que cita usando las señales de Google, Page Experience incluido, así que existe una influencia indirecta. Un sitio en rojo no queda excluido, pero compite en peores condiciones.
Referencias
Fuentes oficiales y lecturas recomendadas para profundizar en cada uno de los conceptos tratados en este artículo:
- Core Web Vitals web.dev · Google
- Optimize LCP web.dev · Google
- Optimize INP web.dev · Google
- Optimize CLS web.dev · Google
- Core Web Vitals — Search Central Google Search Central
- Chrome UX Report (CrUX) Chrome for Developers
- PageSpeed Insights Google
- Extensión Web Vitals para Chrome Chrome Web Store
- Chrome DevTools — Performance Chrome for Developers
Si Search Console lleva meses en rojo y no sabes por dónde empezar, en la auditoría SEO completa hago el diagnóstico priorizado por ROI que te ahorra semanas de tocar variables sin plan. Y si quieres una segunda opinión antes de decidir si migrar de framework o de hosting, mejor hablamos en consultoría.
