JavaScript and Node.js performance profiling

Use this skill for Node.js workloads. For browser JavaScript, rendering, network waterfalls, or browser main-thread work, use browser-javascript-profiling instead.

Prefer built-in Node.js facilities before native profiler packages. A useful profile requires a representative workload that finishes successfully; validate that first.

Choose the profiler by question

Question	First tool	Artifact	Important limitation
Which JavaScript/native call paths consume CPU?	`node --cpu-prof`	`.cpuprofile`	Sampling can miss short work; CPU attribution is not wall-clock latency
Which call paths allocate the most bytes?	`node --heap-prof`	`.heapprofile`	Samples allocations, not the objects still retaining memory
Which objects retain memory at one point in time?	`v8.writeHeapSnapshot()`	`.heapsnapshot`	Stops the main thread and can require roughly twice the current heap
Is garbage collection frequent or expensive?	`node --trace-gc`	Diagnostic text	Adds logging overhead and needs representative allocation pressure
Is the event loop delayed?	`perf_hooks.monitorEventLoopDelay()`	Histogram values	Reports delay, not the responsible call path
How long does one operation take?	`performance.mark()` / `performance.measure()`	Performance entries	Instrumentation measures only the marked scope

Do not treat RSS, heap allocation, retained heap, and total allocated bytes as interchangeable. External memory such as Buffer backing stores can increase RSS without appearing as ordinary V8 heap growth.