Otimizar o desempenho do Node começa com medição para encontrar o verdadeiro gargalo — nunca adivinhe. Você perfila uso de CPU, event loop e memória, e depois aplica correções direcionadas. A regra de ouro: perfil primeiro, otimize o que é realmente 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 revelam para onde o tempo vai — um flame graph mostra quais funções dominam a CPU, para que você otimize a coisa certa.
// ❌ synchronous CPU-heavy work blocks ALL request handling
function handler(req, res) {
const result = heavyComputation(); // freezes the event loop → every request stalls
res.json(result);
}
Como Node é single-threaded para JS, qualquer operação síncrona longa bloqueia tudo. Monitore event-loop lag (por exemplo, perf_hooks monitorEventLoopDelay); lag crescente significa que algo está bloqueando o loop. Corrija descarregando trabalho de CPU para worker threads ou uma fila.
✓ Fix N+1 database queries — the most common real bottleneck (batch/join instead)
✓ Add caching (in-memory/Redis) for repeated expensive operations
✓ Add database indexes for slow queries
✓ Use streams for large data instead of buffering it all in memory
✓ Parallelize independent async ops with Promise.all (avoid await waterfalls)
✓ Offload CPU-bound work to worker threads (keep the event loop free)
✓ Use connection pooling for DB/HTTP
✓ Enable gzip/brotli compression for responses
Many "Node is slow" problems are actually slow DB queries (N+1, missing indexes)
or external API latency — profiling reveals this so you fix the real cause.
npx autocannon http://localhost:3000 # measure requests/sec, latency before & after
Meça antes e depois de cada mudança para confirmar que a otimização realmente ajudou.
O trabalho de desempenho é eficaz apenas quando impulsionado por medição — otimizar a coisa errada desperdiça esforço e adiciona complexidade.
Saber como perfil (clinic.js/flame graphs/DevTools para CPU, monitoramento de event-loop lag, análise de heap) permite localizar verdadeiros gargalos, que no Node frequentemente são um event loop bloqueado (corrija com worker threads) ou consultas de banco de dados lentas (N+1, índices ausentes — frequentemente o verdadeiro culpado).
Combinado com caching, streaming, paralelismo e pooling — e verificado com testes de carga — essa disciplina de medir-depois-corrigir é o que transforma um serviço lento em um rápido e escalável.