Finding memory leaks

Turn “the heap keeps growing” into evidence

This lesson is the DevTools investigation companion to memory management. That lesson teaches reachability, mark-and-sweep, and common leak sources. WeakRef & FinalizationRegistry explains why weak references are niche and nondeterministic. Here we use those concepts to find what is holding memory in a real debugging session.

The work is practical: single-page apps navigating between routes, dashboards that run all day, virtualized or infinite lists, modals opened hundreds of times, and developer tools that cache large parsed data. You measure first, isolate one action, compare heap snapshots, read retainers, fix the root, and verify with a new comparison.

Open Chrome DevTools, choose the Memory panel, and pick the profile that matches the question. A Heap snapshot answers “what is reachable now?” Allocation instrumentation on timeline answers “what was allocated during this interaction and remained live?” Allocation sampling answers “which stacks allocate a lot over a longer run?” Detached elements focuses on elements retained by JavaScript references.

Heap snapshots open in views such as Summary, Comparison, Containment, and Statistics. Summary groups by constructor, Comparison shows deltas, Containment starts from roots such as Window and GC roots, and Statistics gives a high-level pie chart. The action bar also includes a collect-garbage button, class filters, and filters such as objects allocated between snapshots or objects retained by detached nodes.

A heap snapshot is not a screenshot of all RAM. It is a graph of reachable JavaScript objects and related DOM nodes. Roots point to objects. Objects point to other objects. The Retainers pane shows incoming references to the selected object. Retained size comes from the dominator tree: if object A dominates object B, every path from roots to B goes through A, so freeing A could also free B.

The next replay uses a deterministic teaching graph. The lesson's run context provides helper functions, so the driver code can run in Edit & run exactly as shown.

1const snapshot = createLeakSnapshot(1);Run2const reachable = computeReachable(snapshot);3const retained = computeRetainedSizes(snapshot);4const path = findRetainerPath(snapshot, "button:1");5 6console.log(reachable.length);7console.log(path.join(" -> "));8console.log(retained["panel:1"]);

The reliable workflow is often called the three-snapshot technique. Load the page and perform one warm-up action so lazy code, caches, and initial listeners settle. Take a baseline snapshot. Repeat the suspected action several times, collect garbage from DevTools, take another snapshot, then switch the later snapshot to Comparison. Growing constructor rows are suspects, not verdicts; the verdict comes from retainers.

1const before = createLeakSnapshot(1);Run2const after = createLeakSnapshot(5);3const diff = diffConstructorCounts(before, after);4const detached = diff.find((row) => row.name === "DetachedHTMLDivElement");5const functions = diff.find((row) => row.name === "Function");6console.log(detached.delta);7console.log(functions.delta);8console.log(diff.filter((row) => row.delta > 0).map((row) => row.name + ":" + row.delta).join(", "));

In Chrome's Summary view, the constructor filter can show Objects allocated between Snapshots 1 and 2. In Comparison view, sort positive deltas, expand the constructor, choose one instance, and read the Retainers pane. The playground below makes those deltas visible without asking the browser to allocate real memory.

1const before = createLeakSnapshot(1);2const after = createLeakSnapshot(5);3const diff = diffConstructorCounts(before, after);4const detached = diff.find((row) => row.name === "DetachedHTMLDivElement");5const functions = diff.find((row) => row.name === "Function");6console.log(detached.delta);7console.log(functions.delta);8console.log(diff.filter((row) => row.delta > 0).map((row) => row.name + ":" + row.delta).join(", "));

A retainer chain is the answer to “who still points at this?” Start at a suspicious instance, then walk the Retainers pane until the chain reaches a root you own. Common endings are a module-level Map, a listener on window, a timer queue callback, a closure context, a framework cache, or an object you pinned in the DevTools console.

• Module cache: a Map stores DOM nodes or route data and never deletes old entries. Fix it with a size cap, explicit deletion, or, for object metadata, WeakMap or WeakSet.
• Event listener: Window or document stores a callback that closes over route data. Fix it with removeEventListener, AbortController, or { once: true } when the behavior is one-shot. Review events for the mechanics.
• Timer: the host timer queue keeps an interval callback alive. Fix it with clearInterval or clearTimeout during teardown; the timers lesson covers the queue behavior.
• Closure: a long-lived callback captures more than it needs. Review closures, then capture an ID or count instead of a whole object graph when that is enough.

A detached DOM node has been removed from the document tree but is still referenced. In snapshots it can appear through detached-element tooling, detached-node filters, or constructor names that make the DOM wrapper obvious. The real clue is the retainer path: an array, listener, closure, cache, or console reference still points at it.

1const retainedNodes = [];2const leakedListeners = [];3 4function mountAndLeakPanel() {5  const panel = document.createElement("section");6  panel.className = "preview-panel";7  panel.textContent = "Preview panel";8  const onResize = () => panel.textContent.length;9  window.addEventListener("resize", onResize);10  document.body.append(panel);11  panel.remove();12  retainedNodes.push(panel);13  leakedListeners.push(onResize);14}15 16mountAndLeakPanel();17console.log(document.querySelector(".preview-panel") === null);18console.log(retainedNodes.length);19console.log(retainedNodes[0].isConnected);20for (const listener of leakedListeners) window.removeEventListener("resize", listener);21retainedNodes.length = 0;

The snippet prints true, 1, and false: the panel is no longer found in the document, one JavaScript array still stores it, and the node's isConnected flag is false. The final two lines clean up this bounded demo.

1const retainedNodes = [];2 3function mountAndCleanPanel() {4  const controller = new AbortController();5  const panel = document.createElement("section");6  panel.className = "preview-panel";7  panel.textContent = "Preview panel";8  const onResize = () => panel.textContent.length;9  window.addEventListener("resize", onResize, { signal: controller.signal });10  document.body.append(panel);11  panel.remove();12  controller.abort();13}14 15mountAndCleanPanel();16console.log(document.querySelector(".preview-panel") === null);17console.log(retainedNodes.length);18console.log("listener aborted");

1const retained = [];2 3function leakyMountUnmount(host) {4  const panel = document.createElement("section");5  panel.textContent = "Preview";6  const onResize = () => panel.textContent.length;7  window.addEventListener("resize", onResize);8  host.append(panel);9  panel.remove();10  retained.push({ panel, onResize });11}12 13function fixedMountUnmount(host) {14  const controller = new AbortController();15  const panel = document.createElement("section");16  panel.textContent = "Preview";17  window.addEventListener("resize", () => panel.textContent.length, { signal: controller.signal });18  host.append(panel);19  panel.remove();20  controller.abort();21}

Heap snapshots answer “what is alive now?” Allocation tools answer “when did it appear?” With Allocations on timeline, record, perform the interaction, stop, and select the time range. Blue bars represent objects still live at the end of the recording; gray bars represent objects that were allocated and later collected. Selecting a constructor shows its retaining tree in the Retainers pane.

Allocation sampling trades precision for lower overhead and a stack-based allocation breakdown. Use it for long-running dashboards or heavy interactions. For a quick trend, open Performance monitor and watch JS heap size while you repeat the action, or record in the Performance panel with the Memory checkbox so heap growth is lined up with script, rendering, and events.

1// Chrome exposes this non-standard property in some contexts.2console.log("memory" in performance);3 4// This newer measurement requires cross-origin isolation headers.5if (crossOriginIsolated && "measureUserAgentSpecificMemory" in performance) {6  const report = await performance.measureUserAgentSpecificMemory();7  console.log(report.bytes);8} else {9  console.log("needs cross-origin isolation");10}

performance.memory is non-standard and Chrome-specific. The newer measureUserAgentSpecificMemory() API requires cross-origin isolation, so it is useful for controlled diagnostics, not as a portable app invariant.

Node uses V8 too, so the same heap snapshot ideas apply. Start a local process with --inspect, open chrome://inspect, choose the Node target, and use the Memory panel. Snapshot creation can block the event loop and temporarily require much more memory, so production triggers must be private and safe to crash.

node --inspect server.js
# Open chrome://inspect, choose the Node target, then use the Memory panel.

1import v8 from "node:v8";2console.log(typeof v8.getHeapStatistics);3console.log(typeof v8.writeHeapSnapshot);4console.log(v8.getHeapStatistics().heap_size_limit > 0);

In this lesson's tests on Node 22, that probe prints function, function, and true. To write an actual snapshot, call v8.writeHeapSnapshot() from a protected diagnostic path, then load the .heapsnapshot file in Chrome DevTools.

1import { writeHeapSnapshot } from "node:v8";2 3// Use a private diagnostics path and protect whatever trigger calls this.4const file = writeHeapSnapshot("./diagnostics/app.heapsnapshot");5console.log(file);

node --heapsnapshot-near-heap-limit=3 server.js
# Node writes up to three snapshots as the heap approaches its limit.

Treat leak hunting like debugging, not fortune-telling. The advanced debugging lesson gives you the same discipline for breakpoints and traces: make the bug repeatable, reduce noise, observe, explain, fix, and verify.

1. Reproduce: Make the leak happen with the smallest repeatable action, such as opening and closing a panel.
2. Measure: Use Performance monitor or the Performance panel Memory checkbox to see whether used JS heap trends up after collection.
3. Isolate: Remove unrelated work, reload, warm up once, then repeat only the suspected action.
4. Compare: Take the three snapshots: warm-up baseline, after one action, after many actions. Compare the later two.
5. Follow retainers: Open a growing constructor, select an instance, and read Retainers until you reach a root you own.
6. Fix and verify: Remove listeners, abort signals, clear timers, cap caches, or use WeakMap/WeakSet when ownership should be weak. Then compare again.

1// Run in a dedicated Node process, not in a normal browser page.2// node --expose-gc leak-regression.test.js3const registry = new FinalizationRegistry((label) => {4  console.log("collected", label);5});6 7(function mountAndUnmount() {8  const marker = { label: "panel" };9  registry.register(marker, "panel");10})();11 12globalThis.gc?.();13await new Promise((resolve) => setTimeout(resolve, 0));14console.log("test can only use this as a best-effort signal");

Common misconceptions

Key takeaways

• The Memory panel gives you heap snapshots, allocation timelines, allocation sampling, and detached-element views.
• A heap snapshot is a reachable-object graph. Retained size comes from dominators, and Retainers explains why an object is alive.
• The three-snapshot technique filters out warm-up noise and highlights repeated growth.
• Detached DOM nodes leak only when JavaScript still references them; follow the retainer chain to the array, listener, closure, cache, or console root.
• Fix the owning root, then run the same comparison again and add an honest regression check.

Up next, the curriculum moves deeper into performance and engine behavior. Keep this workflow handy any time a route, dashboard, or long-lived session keeps getting heavier.