Auditoria Performance

Auditoría de performance — ¿Tu app es ágil o desespera?

> Una app puede funcionar perfecto, respetar la configuración y verse impecable, y aun así perder usuarios porque tarda 5 segundos en cargar o se traba al hacer clic. Esos bugs no rompen nada visiblemente — solo erosionan la experiencia. Esta skill los mide y los arregla.

---

Las 6 dimensiones (cada una con sus umbrales 🟢🟡🔴)

D1 — Core Web Vitals (escritorio + móvil con red 3G simulada)

Las 3 métricas oficiales de Google, medidas con Lighthouse vía Playwright, en el mejor caso (escritorio con fibra) y el peor caso realista (móvil 3G):

| Métrica | Qué mide | 🟢 | 🟡 | 🔴 | |---|---|---|---|---| | LCP | Cuándo aparece el contenido principal | 4s | | INP | Qué tan rápido responde a los clics | 500ms | | CLS | Que el layout no salte al cargar | 0.25 | | Score Lighthouse | Global | ≥90 | 70-89 | 500KB | | JS por ruta | 200KB | | Imagen hero | 500KB | | Total descargado (home) | 2MB | | Fuentes web | 1-2 | 3-4 | >4 |

Típicos: "carga inicial de 850KB → falta code-splitting"; "imagen hero de 2MB → convertir a WebP"; "librería de charts entera importada para una función → tree-shaking".

D3 — Queries SQL lentas

Con pg_stat_statements: resetear stats → navegar la app a fondo → leer las queries más lentas.

| Métrica | 🟢 | 🟡 | 🔴 | |---|---|---|---| | Tiempo medio por query | 500ms | | Tiempo máximo | 3s | | Sequential scans en tablas grandes (>10k filas) | 0 | 1-2 | >2 |

Típico: "el listado ordenado por fecha tarda 2.3s → falta índice en (cliente_id, created_at)".

D4 — Tiempo de respuesta de las APIs

Capturar el Network durante la navegación, calcular p50 y p95 por endpoint.

| Métrica | 🟢 | 🟡 | 🔴 | |---|---|---|---| | Endpoint p50 | 500ms | | Endpoint p95 | 1.5s | | TTFB inicial | 1.5s |

Típico: "la acción hace 3 queries secuenciales que podrían ir en paralelo con Promise.all".

D5 — Fugas de memoria (sesión prolongada)

Medir la memoria base, navegar 15-30 min haciendo flujos repetitivos (abrir/cerrar modales, cambiar filtros, ir y volver entre páginas), medir la memoria final.

| Crecimiento tras 15 min | 🟢 | 🟡 | 🔴 | |---|---|---|---| | memoria final / inicial | 3x |

Típico: "la memoria creció de 45MB a 380MB → un componente no limpia sus event listeners (useEffect sin cleanup)"; "el stream del agente mantiene el EventSource abierto tras cerrar el chat".

D6 — Queries N+1

Resetear stats → cargar un listado → contar las queries. Si el número crece con la cantidad de items, es N+1.

| Listado de N items | Queries esperadas | Bug si… | |---|---|---| | Simple, sin relaciones | 1-2 | >5 | | Con 1 relación | 2-3 | >N/2 | | Con 2-3 relaciones | 3-5 | proporcional a N |

Típico: "un listado de 50 items dispara 51 queries → falta un JOIN".

---

El flujo

1. Detectar el alcance (app completa o lo que el usuario indique).
2. Medir las 6 dimensiones con navegador real + Lighthouse + queries a la base. Cada hallazgo lleva su semáforo.
3. Loop medir-arreglar-remedir: atacar primero los 🔴, luego los 🟡 baratos. Cada fix se re-mide para confirmar la mejora (no solo "debería ser más rápido" — comprobarlo).
4. Pausar y preguntar si la mejora exige un cambio de arquitectura mayor (migrar un proceso pesado fuera de serverless, rediseñar el modelo de datos).
5. Limpieza: stats reseteadas, registros de prueba borrados, base idéntica al estado previo.
6. Reporte semáforo + autorización. El push/deploy lo autoriza el dueño.

---

Reglas duras

1. Medir, no suponer. Cada hallazgo viene de una medición real (Lighthouse, pg_stat_statements, Network), no de "esto se ve pesado".
2. Re-medir tras cada fix para confirmar la mejora con números.
3. Atacar 🔴 primero, luego 🟡 baratos; 🟢 se deja.
4. Pausar por cambio de arquitectura mayor, no por dificultad.
5. El push/deploy lo autoriza el dueño.

---

Anti-patrones (prohibidos)

• "Le metí caché, ya debe ir más rápido." → Re-medir y comprobar con números.
• "El build no se quejó del tamaño." → El framework no avisa; hay que leer el reporte de bundle.
• "Funciona rápido en mi máquina." → Medir en móvil 3G simulado, que es el usuario real.
• "Optimicé la query que se me ocurrió." → Optimizar la que pg_stat_statements señala como la más lenta, con datos.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: LalakinSkywalker
• Source: LalakinSkywalker/bluntag-claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.