Node のパフォーマンス最適化は、推測ではなく計測して実際のボトルネックを特定することから始まります。CPU 使用率、event loop、メモリをプロファイリングし、その上で的を絞った修正を加えます。鉄則は「まずプロファイリングし、本当に遅い箇所を最適化する」ことです。
# CPU プロファイリング — どの関数が CPU 時間を消費しているか特定する
node --prof app.js
node --prof-process isolate-*.
npx clinic doctor -- node app.js
npx clinic flame -- node app.js
node --inspect app.js
これらは時間がどこに使われているかを明らかにします。flame graph はどの関数が CPU を支配しているかを示すので、正しい対象を最適化できます。
// ❌ 同期的な CPU 負荷の高い処理がすべてのリクエスト処理をブロックする
function handler(req, res) {
const result = heavyComputation(); // event loop を凍結 → すべてのリクエストが滞る
res.json(result);
}
Node は JS を単一スレッドで実行するため、長い同期処理はすべてをブロックします。**event loop の遅延（event-loop lag）**を監視し（例：perf_hooks の monitorEventLoopDelay）、遅延の増加は何かがループをブロックしているサインです。CPU 処理を worker threads やキューにオフロードして解決します。
✓ N+1 のデータベースクエリを修正する — 最も多い実際のボトルネック（batch/join に置き換える）
✓ 繰り返される高コストな処理にキャッシュ（in-memory/Redis）を追加する
✓ 遅いクエリにデータベースのインデックスを追加する
✓ 大きなデータはすべてメモリにバッファせず streams を使う
✓ 独立した async 処理を Promise.all で並列化する（await の連鎖を避ける）
✓ CPU バウンドな処理を worker threads にオフロードする（event loop を空けておく）
✓ DB/HTTP に connection pooling を使う
✓ レスポンスに gzip/brotli compression を有効化する
「Node が遅い」という問題の多くは、実際には遅い DB クエリ（N+1、インデックス不足）や
外部 API のレイテンシーが原因です。プロファイリングがこれを明らかにし、真の原因を修正できます。
npx autocannon http://localhost:3000 # 変更前後の requests/sec、レイテンシーを計測
各変更の前後で計測し、最適化が本当に効果があったか確認します。
パフォーマンス改善は計測に基づいて初めて効果を発揮します。間違った対象を最適化すると労力を浪費し、複雑さを増すだけです。
プロファイリングの方法（CPU には clinic.js/flame graph/DevTools、event-loop lag の監視、ヒープ解析）を知っていれば、真のボトルネックを特定できます。Node ではそれが多くの場合、ブロックされた event loop（worker threads で解決）か、遅いデータベースクエリ（N+1、インデックス不足 — しばしば真犯人）です。
キャッシュ、ストリーミング、並列化、プーリングと組み合わせ、負荷テストで検証する。この「計測してから直す」規律こそが、もたつくサービスを高速でスケーラブルなものに変えるのです。