Core Web Vitals de una web hecha con IA (2026): ¿pasa el test de Google?
¿Qué son los Core Web Vitals (LCP, INP y CLS)?
Los Core Web Vitals son las tres métricas con las que Google mide, con usuarios reales, si una página carga rápido, responde rápido al toque o al clic, y no salta mientras la usas. No son una opinión ni un "se ve fluida": son números concretos.
- LCP (Largest Contentful Paint): cuánto tarda en pintarse el elemento más grande de la pantalla (normalmente la imagen o el titular principal). Mide la velocidad de carga percibida.
- INP (Interaction to Next Paint): cuánto tarda la página en responder visualmente después de que alguien haga clic, toque o escriba. Mide la capacidad de respuesta. Sustituyó a FID (First Input Delay) como Core Web Vital el 12 de marzo de 2024, porque FID solo medía el primer clic y INP mide toda la sesión.
- CLS (Cumulative Layout Shift): cuánto "salta" el contenido mientras carga (un botón que se mueve justo cuando ibas a pulsarlo). Mide la estabilidad visual.
La analogía es la de un cartel en la calle: de nada sirve que el cartel sea precioso si tarda en aparecer (LCP), si al tocarlo no reacciona (INP) o si se mueve justo cuando vas a leerlo (CLS). Google mide estas tres cosas con datos de campo reales —el Chrome UX Report (CrUX), que agrega el comportamiento real de usuarios de Chrome, no una simulación de laboratorio— y considera una página "buena" cuando el 75% de sus visitas reales cumple el umbral bueno en las tres métricas a la vez.
Dicho en una frase: un buen Core Web Vitals es tener las tres métricas en verde —LCP por debajo de 2,5 s, INP por debajo de 200 ms y CLS por debajo de 0,1— en al menos el 75% de tus visitas reales. Si una sola de las tres se queda en ámbar o rojo, la página no "aprueba".
¿Por qué una web hecha con IA suele suspenderlos?
Las herramientas de generación de webs con IA (Lovable, v0, Wix ADI, o un sitio montado pegando bloques que sugiere ChatGPT) están optimizadas para producir una interfaz visualmente correcta rápido, no un código ligero. Los problemas se repiten:
- JavaScript de más: librerías genéricas completas para usar solo una parte, que el navegador tiene que descargar y ejecutar igual. Retrasa el LCP y empeora el INP.
- Imágenes sin optimizar: fotos o capturas subidas a tamaño y peso original, sin comprimir ni redimensionar al hueco real que ocupan. Es la causa más habitual de un LCP alto.
- Elementos sin dimensiones reservadas: banners, fuentes web o bloques de anuncios que "entran" después y empujan el resto del contenido. Es lo que dispara el CLS.
- Animaciones y librerías de diseño de más: efectos vistosos que añaden peso y bloquean el hilo principal del navegador, empeorando el INP.
Nada de esto se ve a simple vista: la web puede parecer perfecta en el móvil de quien la construyó y aun así suspender los tres Core Web Vitals para el resto de sus visitantes.
¿La velocidad web afecta al SEO y a las ventas?
Sí, y por dos vías distintas. En Google, los Core Web Vitals forman parte de la señal de "experiencia de página" dentro del conjunto de factores de posicionamiento: no es el único factor, pero una web que los suspende parte con desventaja frente a una que los aprueba. Y en el negocio, hay un dato con método publicado: el informe "Milliseconds Make Millions" (fifty-five y Deloitte Digital, encargado por Google, 2020 — 30 millones de sesiones móviles analizadas en 37 marcas de retail, viajes y lujo) midió que una mejora de solo 0,1 segundos en la velocidad móvil se asoció, en el sector retail, a un +8,4% en la conversión y a un +9,2% en el valor medio del pedido.
Traducido: no hace falta duplicar la velocidad para notar el efecto en las ventas. Décimas de segundo ya mueven la aguja.
| Core Web Vital | Qué mide | Bueno | Mejorable | Malo |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Velocidad de carga del contenido principal | ≤ 2,5 s | 2,5 s – 4 s | > 4 s |
| INP (Interaction to Next Paint) | Capacidad de respuesta a la interacción | ≤ 200 ms | 200 ms – 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Estabilidad visual (sin saltos) | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Umbrales medidos en el percentil 75 de las visitas reales. Fuente: web.dev / Google, "How the Core Web Vitals metrics thresholds were defined".
¿Cómo hago un test de velocidad web y arreglo los Core Web Vitals?
Un plan realista para mejorar la velocidad web, en cinco pasos:
- Haz un test de velocidad web de tu URL en PageSpeed Insights (gratis, de Google): te da tanto el dato de laboratorio como el de campo, si tu web tiene tráfico suficiente en CrUX.
- Distingue campo de laboratorio. El CrUX son usuarios reales con sus móviles y conexiones reales; Lighthouse es una simulación de un único dispositivo. Si solo tienes el dato de laboratorio, trátalo como una estimación, no como la verdad final.
- Para mejorar el LCP: comprime y dimensiona la imagen o el vídeo principal, y sírvelo en un formato moderno (WebP/AVIF).
- Para mejorar el INP: elimina JavaScript de terceros que no necesites y difiere el que no sea crítico para lo que se ve primero.
- Para mejorar el CLS: reserva siempre el espacio (ancho y alto) de imágenes, fuentes y bloques de anuncios antes de que carguen.
Y recomprueba después de cada cambio: los Core Web Vitals no se arreglan una vez y se olvidan, se mantienen con cada actualización de la web —igual que la accesibilidad—.
Aquí está la parte que nos importa como studio: el mismo código que hace que una web sea rápida —HTML semántico, JavaScript solo el necesario, imágenes optimizadas— es el que la hace accesible y el que mejor leen y citan Google y la IA. No son proyectos distintos: por eso en c6n cada web se construye con rendimiento, accesibilidad y visibilidad SEO + GEO de serie, en vez de "vomitarla" con una herramienta de IA y confiar en que se vea bien.
"El código limpio, escrito a mano, gana a la web 'vomitada' por una IA generativa por la misma razón dos veces: es lo que la hace rápida y es lo que la hace citable. Rendimiento y visibilidad en la IA se construyen con los mismos cimientos." — Juan, founder de c6n
¿La web que te montaron (con o sin IA) pasa los Core Web Vitals?
En el diagnóstico gratuito de 48 horas medimos el LCP, el INP y el CLS reales de tu web —o de la que te generó una herramienta de IA— con datos de campo, y te decimos exactamente qué priorizar. Sin humo y con la lista de lo que de verdad importa.
Hablar con CA.IA — gratisDiagnóstico en 48h · Máximo 4 clientes activos · c6n.eu
Fuentes
- Google — web.dev / Chrome Developers: "Web Vitals" (definición de Core Web Vitals, LCP, INP y CLS). web.dev/articles/vitals.
- Google — web.dev: "Largest Contentful Paint (LCP)" — definición y umbrales (bueno ≤ 2,5 s, mejorable 2,5–4 s, malo > 4 s, en el percentil 75 de las visitas). web.dev/articles/lcp.
- Google — web.dev: "Interaction to Next Paint (INP)" — definición y umbrales (bueno ≤ 200 ms, mejorable 200–500 ms, malo > 500 ms). INP sustituyó a FID (First Input Delay) como Core Web Vital el 12 de marzo de 2024. web.dev/articles/inp · web.dev/blog/inp-cwv-march-12.
- Google — web.dev: "Cumulative Layout Shift (CLS)" — definición y umbrales (bueno ≤ 0,1, mejorable 0,1–0,25, malo > 0,25). web.dev/articles/cls.
- Google — web.dev: "How the Core Web Vitals metrics thresholds were defined" — metodología del percentil 75 y de los tres tramos (bueno / mejorable / malo). web.dev/articles/defining-core-web-vitals-thresholds.
- Chrome UX Report (CrUX) — conjunto de datos de campo de Google con la experiencia real de usuarios de Chrome, usado para evaluar los Core Web Vitals a nivel de origen y de página. developer.chrome.com/docs/crux.
- fifty-five y Deloitte Digital, encargado por Google: "Milliseconds Make Millions" (2020). Análisis de 30 millones de sesiones móviles de 37 marcas de retail, viajes y lujo: una mejora de 0,1 s en la velocidad móvil se asoció a +8,4% de conversión y +9,2% de valor medio del pedido en retail. Estudio patrocinado por Google; cifras de fifty-five/Deloitte Digital, no de c6n.