Optymalizacja wydajności Node zaczyna się od pomiaru w celu znalezienia prawdziwego wąskiego gardła — nigdy nie zgaduj. Profilujesz użycie CPU, event loop i pamięć, a następnie stosujesz ukierunkowane poprawki. Złota zasada: najpierw profil, optymalizuj to, co jest naprawdę powolne.
node --prof app.js
node --prof-process isolate-*.
npx clinic doctor -- node app.js
npx clinic flame -- node app.js
node --inspect app.js
Te ujawniają gdzie spędzany jest czas — flame graph pokazuje, które funkcje dominują CPU, więc optymalizujesz właściwe rzeczy.
// ❌ 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);
}
Ponieważ Node jest jednowątkowy dla JS, każda długa operacja synchroniczna blokuje wszystko. Monitoruj event-loop lag (np. perf_hooks monitorEventLoopDelay); rosnące opóźnienie oznacza, że coś blokuje pętlę. Napraw, przenosząc pracę CPU do worker threads lub kolejki.
✓ 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
Pomiar przed i po każdej zmianie, aby potwierdzić, że optymalizacja rzeczywiście pomogła.
Praca nad wydajnością jest efektywna tylko wtedy, gdy napędzana pomiarem — optymalizacja złych rzeczy marnuje wysiłek i dodaje złożoność.
Znajomość sposobu profilowania (clinic.js/flame graphs/DevTools dla CPU, monitorowanie event-loop lag, analiza heap) pozwala zlokalizować rzeczywiste wąskie gardła, które w Node są często zablokowaną pętlą zdarzeń (napraw za pomocą worker threads) lub powolnymi zapytaniami do bazy danych (N+1, brakujące indeksy — często prawdziwy winowajca).
W połączeniu z cachowaniem, przesyłaniem strumieniowym, równolegością i poolingiem — oraz weryfikacją za pomocą testów obciążeniowych — ta dyscyplina miary, a następnie naprawy to to, co zmienia powolną usługę w szybką, skalowalną.