Depuración de Web Vitals en frontends creados por IA: soluciones concretas

Cómo se manifiestan los problemas de Web Vitals en aplicaciones reales

Los malos Web Vitals rara vez se sienten como “un número está fuera de lugar”. Se sienten como un sitio que parece listo, pero no lo está.

Cuando LCP va mal, la gente mira un área en blanco o un marcador de baja calidad demasiado tiempo, y luego el contenido principal aparece de golpe. A veces es obvio, como un titular del hero que aparece tarde. A veces es sutil, como la imagen del producto que tarda una eternidad mientras el resto ya es visible.

Cuando CLS va mal, la página se mueve bajo el usuario. Intentas tocar un botón y éste se desplaza porque se cargó un banner, cambió una fuente o una imagen finalmente obtuvo su altura.

Cuando INP va mal, la página parece cargada pero se siente lenta. Los toques y clics tardan en responder, los inputs se entrecortan y los menús se abren tarde.

Los frontends generados por IA a menudo retroceden tras pequeños cambios porque el layout, la obtención de datos y los efectos secundarios acaban enredados dentro de los mismos componentes. Un cambio “pequeño” como añadir una insignia, cambiar una fuente o renderizar condicionalmente una promoción puede desplazar la disposición inicial, retrasar el elemento más grande o añadir trabajo extra justo cuando el usuario interactúa.

El objetivo es sencillo: cuando una métrica sube, quieres decir, “es este elemento dentro de este componente, y empeoró después de este cambio”. Eso hace las correcciones más seguras, fáciles de repetir y más sencillas de verificar.

Establece una línea base reproducible antes de cambiar nada

El trabajo de rendimiento solo importa si puedes demostrar que mejoraste algo.

Empieza manteniendo tu configuración consistente: Chrome (estable), DevTools y una build parecida a producción (minificada, mismas feature flags, mismos endpoints API si es posible). Elige una página de prueba estable donde el contenido no cambie mucho entre ejecuciones. Si tu app necesita login, crea una cuenta de prueba dedicada con datos consistentes.

Limita el alcance a 1–3 páginas de alto valor. Para muchos frontends generados por IA, eso suele ser una landing pública (primera impresión), una página de precios (conversión) y un flujo “de dinero” como checkout o una pantalla clave del dashboard. Si intentas arreglar todo a la vez, es difícil saber qué ayudó.

Mantén las ejecuciones comparables. Usa el mismo dispositivo cada vez, el mismo perfil de red en DevTools y los mismos pasos (pestaña nueva, recarga completa, mismos clics). Incluso pequeñas diferencias, como una extensión inyectando scripts o un dataset distinto, pueden hacer que INP y CLS parezcan mejores o peores por accidente.

Anota tu línea base en lenguaje claro:

• Fecha, página, build/commit
• Números de LCP/CLS/INP que viste
• Una frase sobre qué se sentía mal (ejemplo: “la imagen del hero aparece y empuja el titular hacia abajo”)

Esa nota es tu control de realidad más tarde, especialmente en UIs generadas por IA donde una “corrección” puede mover el problema a otro componente.

Datos de campo vs datos de laboratorio: cuándo usar cada uno

Depurar es más rápido cuando separas dos preguntas: “¿Qué sienten los usuarios reales?” y “¿Qué puedo reproducir y arreglar hoy?”. Los datos de campo responden la primera. Los datos de laboratorio responden la segunda. Normalmente necesitarás ambos para no perseguir lo equivocado.

Los datos de campo (monitorización de usuarios reales, analítica o datos tipo Chrome UX Report) muestran tendencias entre dispositivos, redes, rutas y comportamientos. Son la mejor forma de confirmar si LCP, CLS o INP están realmente mal en producción y en qué páginas.

Los datos de laboratorio (ejecuciones de Lighthouse, grabaciones de Performance en DevTools, pruebas con red estrangulada) son donde se hace el trabajo. Te permiten reproducir el mismo escenario, inspeccionar qué se pintó y ver qué tarea bloqueó la entrada. Los resultados de laboratorio pueden ser ruidosos, pero son controlables.

Una forma práctica de combinarlos:

• Usa datos de campo para elegir la plantilla de página y la métrica peor (por ejemplo, CLS en móvil en la landing).
• Reprodúcelo en laboratorio y graba hasta poder disparar el mismo tipo de salto o retraso.
• Arregla una cosa a la vez: un componente, una imagen o un comportamiento de script.
• Verifica dos veces: el laboratorio debería mejorar inmediatamente; el campo debería mejorar con el tiempo a medida que los usuarios obtienen la nueva versión.

Si solo puedes elegir una fuente para decidir qué desplegar, confía primero en un problema reproducible en laboratorio y usa los datos de campo como confirmación.

Cómo trazar LCP hasta el elemento y componente exactos

LCP suele ser una gran cosa que el usuario espera ver: una imagen del hero, un titular, una tarjeta de producto o un bloque de cabecera completo. El trabajo es identificar ese elemento exacto y luego retroceder hasta el componente y lo que está esperando.

Encuentra el elemento LCP en un trace de Performance

En Chrome DevTools, graba un trace de Performance mientras cargas la página (incógnito ayuda y usa un perfil de red normal). En el trace, busca el marcador LCP y haz clic para ver el elemento reportado.

Un flujo simple que funciona en la mayoría de frontends generados por IA:

• Empieza a grabar en Performance y luego recarga la página.
• Encuentra el marcador LCP en la línea de tiempo.
• Haz clic y anota el elemento LCP (etiqueta, tamaño y cualquier URL de imagen).
• Usa el nodo resaltado para saltar al DOM.
• Identifica a qué bloque UI pertenece (hero, header, tarjeta por encima del pliegue).

Mapea de nuevo al componente y sus dependencias

Una vez que conozcas el elemento, pregunta dónde se crea. En apps React/Next.js suele ser un componente Hero que obtiene datos, carga una imagen y aplica estilos.

Si el elemento LCP es una imagen, verifica si se sirve al tamaño correcto y si empieza a descargarse suficientemente pronto. Si es texto, presta atención a las fuentes y al CSS.

Luego lista lo que el componente necesita antes de poder renderizarse. Causas comunes:

• Imagen de hero sobredimensionada, o imagen sin dimensiones
• CSS que bloquea el render o archivos de fuentes grandes que retrasan la pintura de texto
• Fetch de datos en cliente que bloquea el hero (un estado de carga se convierte en el “contenido”)
• JavaScript pesado en la primera vista (trabajo de hidratación que bloquea el render)

Un patrón común generado por IA es construir el hero a partir de un fetch en cliente a un CMS, lo que significa que el hero espera a JavaScript y datos. Arreglar esa dependencia puede reducir LCP sin tocar el resto de la página.

Cómo encontrar la fuente de los saltos de diseño (CLS)

CLS es la puntuación de “saltar en la página”. Ocurre cuando algo cambia de tamaño después de que la página parece cargada. El navegador calcula el layout, luego aparece (o crece) un elemento tardío y todo lo de abajo se desplaza.

Para capturarlo, usa la visualización de layout shift del navegador. En Chrome DevTools, graba un trace de Performance mientras recargas la página y haces un desplazamiento rápido. Verás eventos “Layout Shift” en la línea de tiempo, además de regiones resaltadas que muestran qué se movió. Haz clic en un evento de shift y busca los detalles “Moved from / Moved to” y el elemento que lo desencadenó.

Una vez que tengas el elemento, pregunta: ¿qué cambió su tamaño tarde?

La mayoría de los bugs de CLS vienen de un conjunto reducido de patrones:

• Medios sin dimensiones (imágenes, embeds de vídeo, iframes)
• Intercambios de fuentes que cambian el ancho del texto y los saltos de línea
• Banners tardíos (consentimiento de cookies, barras promocionales, widgets de chat) inyectados después de la primera pintura
• Bloques asíncronos (reseñas, recomendaciones, secciones personalizadas)
• Estados colapsables (errores de validación, acordeones) que aparecen sin espacio reservado

Elige la corrección según la causa. Si el contenido debe aparecer, reserva espacio con dimensiones explícitas, aspect-ratio o una caja placeholder. Si es UI opcional (como una barra promocional), muéstrala sin empujar el layout o demórala hasta que el contenido principal sea estable.

Ejemplo: una landing carga una imagen del hero sin dimensiones y luego inyecta una barra “Obtén 10% de descuento” tras 2 segundos. El trace mostrará dos saltos: uno ligado al elemento de la imagen del hero y otro a la contenedor de la barra. Reservar el espacio del hero y hacer que la barra sea un overlay sobre el header suele arreglar ambos.

Cómo localizar retrasos de interacción (INP)

INP es el tiempo entre una acción del usuario (clic, toque, pulsación de tecla) y una respuesta visible en la página. Si alguien clickea un botón y no pasa nada por un momento, esa brecha es lo que captura INP.

La forma más rápida de encontrar la causa es grabar una interacción real y buscar trabajo que bloquee el hilo principal.

Abre DevTools Performance, empieza una grabación y haz la acción exacta que se siente lenta (abrir un menú, escribir en un campo de búsqueda, abrir un modal). Detén la grabación y busca una brecha larga justo después del evento de entrada, normalmente mostrada como tareas largas (a menudo de 50 ms+).

Cuando encuentres una tarea larga, conéctala al código comprobando qué estaba ocurriendo en esa ventana. Culpables comunes en UIs generadas por IA:

• Render pesado (toda la página vuelve a renderizar por un pequeño cambio de estado)
• Listas o tablas grandes (cientos de filas a la vez)
• Actualizaciones de estado costosas (clonado profundo, ordenación, filtrado en cada pulsación)
• Scripts de terceros (analítica, chat) ejecutándose durante interacciones
• Thrash de layout (JS leyendo y escribiendo layout repetidamente)

Una triage rápida ayuda porque la solución difiere según el caso:

• Lag en la primera interacción suele apuntar a código cargado de forma perezosa, carga de fuentes o un componente grande montándose por primera vez.
• Lag en cada interacción normalmente significa trabajo de render repetido, estado ruidoso o manejadores de eventos haciendo demasiado.

Ejemplo: al clicar “Añadir al carrito” se vuelve a renderizar todo el grid de productos porque el estado del carrito vive demasiado arriba en el árbol. INP mejora si aíslas el estado al widget del carrito y evitas que el grid se rerenderice en cada clic.

Arreglos prácticos que reducen CLS rápidamente

CLS suele bajar rápido cuando evitas que la página cambie de tamaño después de aparecer por primera vez. Las victorias rápidas son las aburridas: reserva espacio, estabiliza la tipografía y evita UI sorpresa que aparezca de golpe.

Reserva espacio para cualquier cosa que cargue después

Si una imagen, vídeo, slot de anuncio o iframe llega sin una caja definida, el navegador adivina y luego corrige, y todo salta.

Define dimensiones explícitas donde puedas. Usa width y height en imágenes, o aspect-ratio en CSS para que el navegador conozca la forma antes de descargar el archivo. Si usas skeleton loaders, dales una altura fija que coincida con el contenido real.

Estabiliza las fuentes para que el texto no refluya

Los intercambios tardíos de fuentes cambian saltos de línea y empujan botones. Mantén la fuente de fallback cercana en tamaño y espaciado, y evita cambiar pesos después de la primera pintura. Si un titular salta cuando carga la web font, elige un fallback con métricas similares y mantén estilos iniciales consistentes.

Elimina o doma inyecciones de UI tardías

Toasts, banners de cookies, widgets de chat y barras de “nuevo mensaje” a menudo aparecen después de que la página ya es visible. Ponlos en un lugar consistente y reservado desde el inicio, o muéstralos como overlays en vez de empujar el contenido hacia abajo.

Si quieres una pasada corta y de alto impacto, céntrate en:

• Dimensiones (o aspect-ratio) para medios por encima del pliegue
• Una altura mínima fija para secciones hero y skeletons
• Banners y widgets que rendericen dentro de un contenedor con espacio reservado
• Evitar insertar nuevo contenido por encima del pliegue después de la primera pintura

Cambios que suelen mejorar LCP e INP sin reescribir todo

Cuando una UI generada por IA se siente lenta, suele ser porque demasiado trabajo ocurre antes de que la primera pantalla sea totalmente visible. Ayuda enfocarse en dos objetivos: hacer la primera vista más ligera (LCP) y hacer que los toques y clics ejecuten menos trabajo (INP).

Un patrón común es un hero envuelto en múltiples contenedores, más un carrusel, vídeo de fondo y varios scripts de terceros que empiezan inmediatamente. Puede verse bien en un portátil rápido, pero en un móvil de gama media el hilo principal se satura y todo llega tarde.

Cambios que suelen ayudar sin cambiar toda la arquitectura:

• Reducir el elemento LCP. Si es una imagen, comprímela, usa WebP/AVIF y sirve el tamaño correcto para la pantalla. Si es texto dentro de un wrapper pesado, elimina capas extra y efectos costosos.
• Simplificar lo que está por encima del pliegue. Corta animaciones no críticas, sombras, efectos de desenfoque y widgets complejos en la primera vista. Renderiza la versión más simple primero y luego mejora.
• Demorar scripts no críticos. Carga analítica, widgets de chat y herramientas A/B después del render inicial.
• Fragmentar las tareas largas. Si un clic dispara un cálculo grande o un rerender, divide el trabajo para que el navegador pueda responder rápido.
• Reducir rerenders. Consolida estado, memoiza partes costosas y evita rerenderizar toda la página por un pequeño cambio de UI.

Para INP, revisa detenidamente los handlers de clic. Si un botón hace llamadas de red, validación y actualizaciones de UI todo en un bloque, el usuario espera. Muestra la respuesta UI primero (abre el drawer o modal) y luego realiza el trabajo más pesado.

Mide las mejoras después de cada cambio (sin engañarte)

Es fácil perder horas cambiando algo, ver una buena ejecución y darlo por hecho. Web Vitals son ruidosos. La red, la CPU, extensiones y caches calientes pueden hacer que un cambio parezca mejor (o peor) de lo que es.

Trata cada ajuste como un mini-experimento: cambia una cosa, luego mide. Si haces varios cambios a la vez (común en frontends generados por IA), no sabrás qué ayudó.

Un registro simple basta:

• Qué cambiaste (una sola cosa pequeña)
• Dónde (página/ruta, componente)
• Cómo probaste (dispositivo, throttling, carga fría vs caliente)
• Resultados (LCP, CLS, INP) usando la mediana de 3 ejecuciones
• Evidencia guardada (capturas de trace)

Compara medianas, no mejores ejecuciones. Una mejor ejecución suele ser suerte.

También vigila compensaciones. Puedes arreglar CLS reservando espacio y empeorar LCP cargando más CSS temprano. O mejorar INP fragmentando un componente y luego introducir una imagen de carga tardía que se convierte en el nuevo LCP. Si una corrección mejora una métrica y perjudica otra, decide qué molestia del usuario es mayor y ajusta.

Trampas comunes al depurar Web Vitals en UIs generadas por IA

El trabajo de Web Vitals se tuerce rápido cuando el código parece “bien” pero se comporta distinto en producción. El error más grande es optimizar la puntuación en lugar de la experiencia en las páginas que realmente usan las personas.

Trampas que hacen perder tiempo y crear victorias falsas:

• Perseguir puntos de Lighthouse en una sola ejecución mientras los usuarios reales sufren en login, checkout o precios.
• Probar en modo dev y asumir que esos números coinciden con producción.
• Ocultar contenido, añadir demoras o mostrar skeletons demasiado tiempo para que la métrica mejore pero la página se sienta peor.
• Dejar que una refactorización por IA toque docenas de archivos a la vez, de modo que cuando LCP o INP cambian no sabes por qué.
• Acelerar una página y olvidarte de volver a revisar layouts compartidos y flujos de autenticación.

Ejemplo: una landing “arregla” CLS haciendo que el hero aparezca con fade-in a los 800 ms. CLS mejora, pero los usuarios se quedan mirando una zona superior en blanco y hacen clic en lo incorrecto cuando el contenido finalmente aparece. Es una victoria de métrica con pérdida de producto.

Unas pocas reglas ayudan:

• Mide la misma ruta, perfil de dispositivo y red cada vez.
• Publica un cambio a la vez y confirma que la navegación e inicio de sesión siguen funcionando.
• Considera sospechoso cualquier arreglo que oculte contenido o retrase el render hasta confirmar que realmente ayuda a los usuarios.

Lista rápida para una pasada de 30 minutos sobre Web Vitals

Elige una página y un perfil de dispositivo para hoy. Probar tres páginas y dos tamaños de pantalla quema tiempo y produce resultados difusos.

Haz una ejecución y escribe lo que ves antes de tocar código. Tu trabajo es identificar la mayor causa de dolor única para LCP, CLS e INP en esa página.

• Línea base: registra tiempo de LCP y el elemento LCP exacto (imagen, titular, sección hero).
• CLS: captura los 1–2 saltos de layout principales y qué se movió (hero, banner, intercambio de fuente, widget inyectado).
• INP: registra la interacción más lenta que puedas reproducir y la tarea larga justo después.
• Revisión rápida: asegura que los medios del hero tengan dimensiones fijas, que banners/toasts tengan espacio reservado y que scripts de terceros no bloqueen el primer render.
• Un cambio, una nueva ejecución: haz una sola corrección, vuelve a ejecutar la misma prueba y registra los nuevos números.

Si el elemento LCP es la imagen del hero y la página salta cuando aparece una barra de cookies, arregla el espacio de la barra primero (CLS), luego fija las dimensiones de la imagen del hero y su comportamiento de carga (LCP). No mezcles cinco “pequeños ajustes” en un solo commit o no sabrás qué ayudó.

Para cuando detenerte: cuando las mejoras sean pequeñas o la siguiente corrección requiera refactorizar. Si la UI fue generada por una herramienta de IA y el código está enmarañado, planifica el siguiente cuello de botella como un bloque de trabajo separado.

Ejemplo: convertir una landing AI-built y saltarina en una estable

Una landing típica generada por IA se ve bien en capturas, pero salta al cargar: imagen grande del hero arriba, tarjetas de precios abajo y un slider de testimonios que aparece tarde.

En un proyecto así, la historia quedó clara tras medir: LCP era la imagen del hero, CLS venía de un intercambio de fuente más el slider que cambiaba de altura al cargarse, e INP sufría por una librería de animación pesada ejecutándose temprano.

La secuencia que lo arregló sin reescritura:

• Bloquear el tamaño de la imagen del hero con dimensiones explícitas o aspect-ratio.
• Reservar espacio para el slider de testimonios con una altura fija (o min-height predecible).
• Retrasar o reducir animaciones tempranas para que los toques y el scroll se sientan inmediatos.

Para mantener la honestidad, registra lo mismo antes y después de cada cambio:

Si reservaste espacio, eliminaste los mayores saltos de layout y retrasaste trabajo no esencial pero las métricas aún rebotan porque el árbol de componentes está enmarañado, suele ser más rápido reestructurar esa sección que seguir pinchando sobre síntomas.

Siguientes pasos si el frontend está demasiado desordenado para optimizar con seguridad

Si no puedes mapear de forma fiable LCP, CLS o INP a un elemento específico y al componente que lo creó, probablemente necesites limpieza antes de afinar. Este trabajo solo paga cuando puedes trazar una métrica hasta una causa concreta y verificar el impacto tras un pequeño cambio.

Los frontends generados por IA a menudo se ven bien en la superficie pero esconden un desastre debajo: componentes duplicados, estilos inline por todas partes, rerenders sorpresa y cambios de layout disparados por datos tardíos. En esa situación, las “soluciones rápidas” pueden crear un nuevo salto de layout, o reducir LCP mientras empeoran INP.

Un camino más seguro es una pasada corta de triage:

• Elige una página que importe (a menudo la landing o el flujo de registro).
• Captura una línea base: algunos traces de performance y una lista de los mayores elementos LCP y los saltos de layout principales.
• Identifica lo que realmente puedes controlar (un componente, una ruta, un sistema de layout).
• Decide: pequeño refactor primero, o limpieza más profunda antes de tocar métricas.

Una señal clara para dejar de juguetear y refactorizar: cambias un componente hero para arreglar LCP, pero el header empieza a saltar porque el espaciado se define en tres sitios (módulo CSS, estilo inline, div wrapper). Si no puedes predecir qué se moverá, estás adivinando.

Si heredaste código generado por IA y necesitas que sea lo bastante estable para que las correcciones de rendimiento funcionen, FixMyMess trabaja exactamente en este tipo de remediación: diagnostica prototipos desordenados creados con herramientas como Lovable, Bolt, v0, Cursor y Replit, y luego los repara y refactoriza con verificación humana. Si quieres una segunda opinión antes de invertir en una reescritura mayor, su auditoría de código gratuita puede ayudar a señalar qué está impulsando LCP/CLS/INP en tus páginas clave.

Una vez que la base de código sea predecible otra vez, vuelve al bucle simple: línea base, un cambio, volver a medir, repetir.