Optimizar el rendimiento de Node comienza por medir para encontrar el cuello de botella real, nunca adivinando. Perfilas el uso de CPU, el event loop y la memoria, y luego aplicas correcciones específicas. La regla de oro: primero perfila, luego optimiza lo que realmente está lento.
node --prof app.js
node --prof-process isolate-*.
npx clinic doctor -- node app.js
npx clinic flame -- node app.js
node --inspect app.js
Estas herramientas revelan dónde se va el tiempo: un flame graph muestra qué funciones dominan la CPU, de modo que optimizas lo correcto.
// ❌ trabajo síncrono intensivo en CPU bloquea TODO el manejo de solicitudes
function handler(req, res) {
const result = heavyComputation(); // congela el event loop → cada solicitud se detiene
res.json(result);
}
Como Node es de un solo hilo para JS, cualquier operación síncrona prolongada bloquea todo. Monitorea el retraso del event loop (event-loop lag, por ejemplo con perf_hooks monitorEventLoopDelay); un lag creciente significa que algo está bloqueando el loop. Corrígelo descargando el trabajo de CPU a worker threads o a una cola.
✓ Corrige consultas N+1 a la base de datos — el cuello de botella real más común (usa batch/join)
✓ Agrega caching (en memoria/Redis) para operaciones costosas repetidas
✓ Agrega índices de base de datos para consultas lentas
✓ Usa streams para datos grandes en lugar de bufferearlos todos en memoria
✓ Paraleliza operaciones async independientes con Promise.all (evita cascadas de await)
✓ Descarga el trabajo intensivo en CPU a worker threads (mantén el event loop libre)
✓ Usa connection pooling para BD/HTTP
✓ Habilita compresión gzip/brotli para las respuestas
Muchos problemas de "Node es lento" en realidad son consultas lentas de BD (N+1, índices faltantes)
o latencia de APIs externas — el profiling lo revela para que corrijas la causa real.
npx autocannon http://localhost:3000 # mide solicitudes/seg, latencia antes y después
Mide antes y después de cada cambio para confirmar que la optimización realmente ayudó.
El trabajo de rendimiento solo es efectivo cuando está impulsado por la medición; optimizar lo equivocado desperdicia esfuerzo y agrega complejidad.
Saber cómo perfilar (clinic.js/flame graphs/DevTools para CPU, monitoreo del event-loop lag, análisis de heap) te permite ubicar cuellos de botella reales, que en Node suelen ser un event loop bloqueado (corregido con worker threads) o consultas lentas de base de datos (N+1, índices faltantes, frecuentemente el verdadero culpable).
Combinado con caching, streaming, paralelismo y pooling, y verificando con pruebas de carga, esta disciplina de medir-y-luego-corregir es lo que convierte un servicio lento en uno rápido y escalable.