Core Web Vitals en una app hecha con IA: qué arreglar primero

Las Core Web Vitals son tres mediciones con las que Google evalúa cómo se siente una página para los visitantes reales: Largest Contentful Paint (LCP) para la carga, Interaction to Next Paint (INP) para la respuesta a la interacción y Cumulative Layout Shift (CLS) para la estabilidad visual. Una página aprueba cuando, en el percentil 75 de las visitas reales, el LCP es de 2,5 segundos o menos, el INP de 200 milisegundos o menos y el CLS de 0,1 o menos. Las apps generadas con herramientas de IA suelen fallar por las mismas pocas razones, y casi todas se corrigen sin reescribir nada.

En esta guía te explicamos cada métrica sin tecnicismos, dónde ver tus números reales, los culpables habituales en una app de React hecha con Lovable, Bolt, v0 o Cursor, y cómo confirmar que un arreglo funcionó.

¿Qué miden exactamente LCP, INP y CLS?

• LCP es el tiempo hasta que aparece el elemento más grande de la primera pantalla (normalmente una imagen principal, un título o un bloque de texto grande). Responde a "¿cuándo parece cargada la página?".
• INP observa los clics, toques y teclas durante toda la visita e informa uno de los retrasos más lentos entre la acción y el siguiente cuadro dibujado. Responde a "¿la página reacciona cuando la toco?". En 2024 reemplazó a First Input Delay como Core Web Vital.
• CLS suma los movimientos inesperados del contenido mientras la página está abierta. Es el botón que salta justo cuando lo vas a tocar.

El percentil 75 importa: te juzgan por la experiencia de tus visitantes más lentos, por separado en móvil y escritorio. Una laptop rápida con el wifi de la oficina dice poco de un teléfono de gama media en el transporte público.

¿Dónde veo mis números reales?

Hay dos tipos de datos y necesitas los dos.

1. Datos de campo, de usuarios reales de Chrome. Están en la parte superior de PageSpeed Insights y en el informe de Core Web Vitals de Google Search Console. Un sitio nuevo o con poco tráfico puede no tener todavía suficientes datos.
2. Datos de laboratorio, de una sola carga simulada. Te los dan Lighthouse en las DevTools de Chrome y la parte inferior de PageSpeed Insights. Lighthouse no puede medir INP porque nadie hace clic; muestra Total Blocking Time como referencia aproximada.

Si no tienes datos de campo, puedes recogerlos tú con la pequeña librería web-vitals de Google y enviarlos a tu herramienta de analítica.

¿Por qué las apps hechas con IA suelen fallar las Core Web Vitals?

Casi todas son apps de React renderizadas en el cliente. El navegador descarga un HTML casi vacío, luego un paquete grande de JavaScript, lo ejecuta, pide los datos y recién entonces dibuja el contenido. Cada paso suma tiempo, y las herramientas agregan algunas costumbres:

• Un solo paquete enorme. Todas las páginas, la librería de gráficos, los iconos y las fechas viajan en la primera carga, incluido el código del panel de administración.
• Imágenes a tamaño completo. Una foto de 4000 píxeles subida desde el teléfono y mostrada a 600 píxeles de ancho.
• Imágenes sin dimensiones. Sin width ni height, el diseño salta cuando llegan.
• Fuentes web que cambian tarde y mueven el texto después de mostrado.
• Datos pedidos en cadena. La página carga el usuario, luego su equipo, luego los proyectos, cada uno esperando al anterior.
• Trabajo pesado en cada tecla. Filtrar una lista larga o volver a dibujar una tabla entera con cada letra.

¿Cómo mejoro el LCP?

1. Identifica el elemento LCP. En las DevTools de Chrome abre el panel Performance (Rendimiento) y graba una carga; la marca de LCP te dice qué elemento fue.
2. Si es una imagen, haz que el navegador la vea en el HTML inicial o precárgala, agrega fetchpriority="high" y nunca la cargues en diferido. Sírvela al tamaño en que se muestra, en WebP o AVIF. Nuestra guía para optimizar las imágenes de tu app lo explica paso a paso.
3. Si es texto, el retraso casi siempre viene del JavaScript y de los datos. Prerenderizar o renderizar en servidor las páginas públicas pone el texto en el HTML desde el principio (mira SEO para apps React SPA).
4. Baja el tiempo de respuesta del servidor. Sirve los archivos estáticos desde una CDN y haz que la primera consulta de datos sea rápida; las consultas lentas a la base de datos también se notan aquí.

¿Cómo mejoro el INP?

Un INP malo significa que el hilo principal está ocupado cuando el usuario interactúa.

• Divide el paquete por rutas (React.lazy e import()), para que la primera página no procese código que no necesita.
• Parte las tareas largas. Si un clic dispara trabajo pesado, muestra primero una respuesta (un indicador de carga, el botón desactivado) y haz lo pesado después del siguiente dibujado.
• Usa debounce en los buscadores y filtra las listas grandes en el servidor, o dibuja solo las filas visibles (virtualización).
• Revisa los scripts de terceros. Chats, gestores de etiquetas y grabadores de sesión suelen ocupar buena parte del hilo principal. Cárgalos cuando la página ya sea interactiva o quita los que no uses.

¿Cómo mejoro el CLS?

• Pon width y height (o aspect-ratio en CSS) a cada imagen y video, para reservar el espacio antes de que carguen.
• Reserva lugar para banners, avisos de cookies y anuncios en vez de empujar el contenido cuando aparecen.
• Usa font-display: swap con una fuente de respaldo de tamaño parecido, o precarga la fuente principal.
• No insertes contenido encima de lo que el usuario está leyendo, salvo que sea respuesta a algo que hizo.

¿Cómo sé que el arreglo funcionó?

Las herramientas de laboratorio responden al instante: vuelve a correr Lighthouse con el mismo tipo de dispositivo y compara. Los datos de campo tardan más. Search Console y PageSpeed Insights usan una ventana móvil de 28 días, así que una mejora real aparece de a poco en las semanas siguientes. En Search Console puedes marcar un problema como corregido e iniciar una validación, que sigue a las URL afectadas.

Anota qué cambiaste y cuándo. Si los números se mueven, sabrás por qué; si no, no repetirás el mismo cambio.

Respuestas rápidas

¿Las Core Web Vitals afectan el posicionamiento en Google? Google usa señales de experiencia en la página, entre ellas las Core Web Vitals, en sus sistemas de clasificación, pero el contenido relevante pesa más. Tómalas como desempate y como algo que influye directamente en las conversiones.

¿Por qué Lighthouse da buena nota pero Search Console dice "deficiente"? Lighthouse es una carga simulada en tu equipo; Search Console refleja a visitantes reales en dispositivos y redes reales durante 28 días.

¿Qué métrica arreglo primero? La que aparece como deficiente en móvil, que es donde más sufren las apps hechas con IA y donde están casi todos los visitantes.

¿Puedo arreglarlo sin salir de Lovable o Bolt? Muchos cambios (tamaño de imágenes, dimensiones, carga diferida, menos scripts) se pueden pedir a la herramienta. Dividir el paquete y prerenderizar suele requerir trabajo directo en el código.

¿Quieres que alguien lo revise?

La revisión gratuita de tu app te da una vista desde afuera en un par de minutos. Si el problema va más allá de imágenes y scripts, nuestros planes de mantenimiento de software incluyen trabajo de rendimiento junto con los arreglos del día a día, o contáctanos y cuéntanos qué ves. La referencia de Google para los umbrales está en la introducción a Web Vitals de web.dev.