Encontrar por qué una página va lenta solo en producción

A quién le sirve. Desarrolladores y equipos técnicos con una web o una app propia que va lenta solo con usuarios y datos reales.

Qué hicieron

Una página cargaba lenta en el servidor real pero no en el entorno de pruebas. El desarrollador pidió a un agente de Cursor (o de Warp) una lista de posibles causas y los pasos para arreglarlas. El agente leyó el código, dedujo qué consultas hacía NestJS a la base de datos y señaló qué índices (atajos que aceleran las búsquedas) había que crear.

Cómo salió

Tras añadir los índices recomendados, la página cargó bastante mejor. La fuente no da tiempos ni cifras.

Conviene saber

El agente solo trabajó con el código y propuso causas posibles. Tú tienes que aplicar los cambios y comprobar en producción que funcionan.

Qué necesitas

• Cursor instalado en tu ordenador (un editor de código con un agente de IA dentro)
• El código de tu aplicación abierto en Cursor
• La página o la petición que va lenta, y saber en qué entorno ocurre
• Una copia de pruebas de la base de datos, con datos parecidos a los reales
• Alguien con permisos para crear índices y desplegar cambios en producción

Cómo hacerlo tú, paso a paso

1. Abre el proyecto en Cursor y apunta qué página o petición va lenta, cuándo pasa y cuánto tarda más o menos.
2. Pega el prompt de la ficha con tu framework (la base sobre la que está hecha tu aplicación, como NestJS) y esa página. Pídele antes una lista de causas posibles, de la más probable a la menos.
3. Pídele que lea el código de esa página y saque las consultas que lanza a la base de datos, que son las peticiones de datos que hace tu aplicación.
4. Para cada consulta, pregúntale qué índices tiene la tabla y cuáles faltan. Un índice es un atajo que acelera las búsquedas.
5. Revisa las propuestas con quien conozca tu base de datos y prueba cada cambio primero en la copia de pruebas.
6. Crea los índices con una migración (un archivo que deja el cambio guardado y repetible), despliega y mide la página otra vez.
7. Si no mejora lo bastante, vuelve al agente con lo que has medido y pídele la siguiente causa de la lista.

Mi aplicación hecha con [framework, por ejemplo NestJS] va lenta en producción pero no en local, en concreto en [página o endpoint]. Lee el código y las consultas a la base de datos que intervienen, localiza las más lentas o repetidas y recomiéndame índices o cambios en las consultas, explicando por qué. Habrás terminado cuando me des una lista ordenada de arreglos con el cambio exacto de código o de migración para cada uno. No ejecutes nada contra la base de datos de producción: enséñame primero los cambios.

Consejos

• Mide el tiempo de carga antes y después de cada cambio. Sin medir no sabrás qué arreglo funcionó.
• No crees todos los índices de golpe: cada uno ocupa espacio y hace algo más lentas las escrituras. Hazlo en un momento de poco tráfico, porque en tablas muy grandes crear un índice puede bloquearlas un rato.
• Cuando el agente diga que una causa es probable, pídele la línea de código donde lo ha visto. Así compruebas que no se lo inventa.

Preguntas frecuentes

Fuentes

• trevorarnold en Substack ↗

En el directorio desde el 3 de octubre de 2026.