Por qué tu app construida con IA se vuelve lenta con usuarios reales

La demo era instantánea. Tres meses después, con unos cientos de clientes y unos miles de registros, el dashboard tarda ocho segundos y los usuarios se están quejando. No se cambió nada, entonces ¿qué pasó?

Los datos crecieron. El código generado por herramientas de IA está escrito para funcionar, y con diez filas de prueba casi cualquier cosa funciona. Los problemas solo aparecen cuando el mismo código se encuentra con volúmenes reales. Este post cubre las seis causas comunes, cómo saber cuál tienes y cómo corregirlas. Forma parte de la guía para preparar un prototipo construido con IA para usuarios reales.

¿Cómo encuentras lo que está lento?

Mide antes de cambiar nada. Abre la página lenta con las herramientas de desarrollador del navegador en la pestaña Network y recarga. Buscas tres cosas: solicitudes que tardan más de un segundo, respuestas muy grandes y decenas de solicitudes donde bastarían unas pocas.

Después revisa la base de datos. En Supabase, ejecuta la consulta lenta con explain analyze en el editor SQL; su documentación sugiere buscar sequential scans y números de costo altos, y ofrece un index advisor que recomienda índices para una consulta determinada (Supabase).

Las seis causas comunes

1. Cargar toda la tabla y filtrar en el navegador

La página pide todos los pedidos y luego los filtra, ordena y cuenta en JavaScript. Con 50 pedidos, no hay problema; con 50.000, el navegador descarga megabytes para mostrar una lista de 20. La solución es pedirle a la base de datos exactamente lo que muestra la página: el filtro, el orden y el límite van en la consulta, y los totales salen de un count o de una pequeña consulta de resumen.

2. Falta de índices

Una consulta que filtra por user_id, status o created_at sin un índice lee toda la tabla cada vez. La recomendación de Supabase es indexar las columnas que se usan en filtros y joins (Supabase). A menudo es la mayor mejora individual, y cuesta una línea de SQL por índice.

3. Políticas de row level security lentas

Las políticas de seguridad se ejecutan en cada fila que toca una consulta. Escritas de la manera obvia, pueden ser la parte más lenta de la consulta. Las propias pruebas de Supabase muestran grandes mejoras con tres cambios: indexar las columnas que usa una política (más de 100 veces más rápido en tablas grandes), envolver auth.uid() en un select (de 179 ms a 9 ms) y agregar el mismo filtro a la propia consulta (de 171 ms a 9 ms) (Supabase). Si todavía no configuraste las políticas, empieza con RLS en Supabase para apps construidas con IA.

4. Una solicitud por elemento

Una lista de 30 proyectos en la que cada tarjeta obtiene por separado a su dueño, sus tareas y sus comentarios hace 90 solicitudes para mostrar una página. La solución es traer los datos relacionados en una sola consulta (Supabase permite seleccionar tablas relacionadas en la misma solicitud) o cargar los detalles solo cuando se abre una tarjeta.

5. Sin paginación

Las listas que cargan “todo” se vuelven más lentas cada día. Peor aún, las APIs limitan cuántas filas devuelve una solicitud, así que una lista puede dejar de mostrar registros nuevos sin avisar una vez que supera ese límite. Pagina los resultados con un limit y un offset o con un cursor, y muestra el total por separado.

6. El plan de hosting

Los planes gratuitos están hechos para probar cosas, no para atender clientes. El plan gratuito de Supabase, por ejemplo, incluye una base de datos de 500 MB y pausa los proyectos después de una semana de inactividad (Supabase); el primer visitante después de una pausa espera a que el proyecto se reactive. Antes del lanzamiento, cámbiate a un plan pago y revisa dónde corren tu base de datos y tu hosting: un servidor en un continente distinto al de tus usuarios agrega demora a cada solicitud.

¿Qué corrección va primero?

Empieza por la página de la que se quejan los usuarios y mide su solicitud más lenta. En la mayoría de las apps construidas con IA el orden es el mismo: primero los índices (minutos para agregarlos, a menudo la mayor mejora), luego las consultas que cargan demasiado, luego la paginación, luego el número de solicitudes por página. Corrige una cosa, vuelve a medir y detente cuando la página sea lo bastante rápida. Reescribir la app por velocidad rara vez es necesario.

Los problemas de velocidad y los de seguridad a menudo comparten una causa: el navegador haciendo un trabajo que debería hacer el servidor. Cuando corrijas uno, revisa el otro; claves secretas en tu frontend cubre el lado de la seguridad.