Memory Tab: Heap Snapshots

Memory Problems Are Invisible Until They're Catastrophic

Here's what makes memory leaks so nasty: they don't throw errors. They don't show up in the Console. Your app works perfectly for 5 minutes, gets sluggish at 10, and crashes at 30. By the time a user reports it, the only symptom is "the app got slow." Without heap snapshots, you're stuck staring at code and hoping to spot the problem. That's not a strategy.

Three Profiling Modes

The Memory panel gives you three distinct tools — and picking the right one upfront saves you from going down the wrong rabbit hole.

1. Heap Snapshot

Question it answers: "What's in memory right now, and why is it there?"

Takes a complete snapshot of the JavaScript heap. You see every object, its size, and the chain of references keeping it alive (the retainer tree). Best for comparing two points in time to find leaks.

2. Allocation Instrumentation on Timeline

Question it answers: "Which objects are being allocated over time, and which survive garbage collection?"

Records a timeline of allocations. Blue bars show objects allocated at that moment. Bars that remain blue were not collected — potential leaks. Bars that disappear were properly GC'd. Best for finding when during a workflow leaks happen.

3. Allocation Sampling

Question it answers: "Which functions are allocating the most memory?"

Low-overhead sampling profiler that attributes memory allocations to the functions that created them. Think of it as a memory-focused flame graph. Best for finding allocation hot spots in production-like scenarios where full instrumentation is too slow.

Reading the Summary View

You took a snapshot. Now you're staring at a table with thousands of rows. Don't worry — once you know what the columns mean, it clicks fast. The default Summary view groups objects by constructor name:

Spotting Anomalies

• Unexpectedly high counts: 50,000 instances of EventListener? That's a leak.
• Large Retained Size with small Shallow Size: The object itself is small but keeps a massive subgraph alive — a closure holding a reference to an entire component tree.
• Detached DOM trees: Appear under Detached HTMLDivElement (or similar). These are DOM nodes removed from the document but still referenced by JavaScript.

The Comparison View: Finding Leaks Systematically

This is where it gets good. The Comparison view is the single most powerful technique for memory leak detection, and once you learn it, you'll wonder how you ever debugged leaks without it:

1. Take Snapshot 1 — This is your baseline. The app is in a clean state.
2. Perform the suspect action — Open a modal, navigate to a page, load data. Then undo it — close the modal, navigate back, clear the data.
3. Force garbage collection — Click the trash can icon in the Memory panel. This ensures anything that can be collected is collected before the next snapshot.
4. Take Snapshot 2 — Select Snapshot 2, then change the view dropdown from "Summary" to "Comparison" and compare against Snapshot 1.

The Comparison view shows:

Sort by # Delta descending. Objects with positive deltas after you've undone the action are still alive when they shouldn't be.

The Retainer Tree: Finding Why Objects Stay Alive

You found a leaked object. Now the real question: why is it still alive? Click on it, and the bottom panel shows the Retainers — the chain of references from the GC root to this object. This is your smoking gun.

Object @123456 (Detached HTMLDivElement)
  ← tooltipRef in Object @789012
    ← scopedVars in functionContext @345678
      ← handleClick in Object @901234
        ← listeners in EventTarget @567890
          ← (GC root: Window)

Read this bottom-to-top: the Window holds an EventTarget, which has a listeners map, which contains a handleClick closure, which captured a scope that includes a tooltipRef variable pointing to the detached DOM node. The fix is to break any link in this chain — remove the event listener, null out the ref, or use a WeakRef.

Understanding GC roots

Objects stay alive because they're reachable from a GC root. In the browser, GC roots include:

• The global object (window/globalThis)
• The currently executing call stack (local variables in running functions)
• Active timers (setInterval/setTimeout callbacks and their closures)
• Active event listeners (handlers attached to live DOM nodes or global targets)
• Active Promises (pending promise chains)
• Active observers (IntersectionObserver, MutationObserver, ResizeObserver callbacks)

If an object is reachable from any root through any chain of references, it cannot be garbage collected. Memory leaks happen when an object is reachable from a root but you no longer need it — the code forgot to break the chain.

Identifying Detached DOM Trees

This is the part that burns people in SPAs. Detached DOM trees are one of the most common memory leaks, and they're sneaky. They happen when JavaScript removes a DOM node from the document but holds onto a reference to it — the node is gone from the page, but very much alive in memory.

In the heap snapshot, type "Detached" in the filter box. All detached DOM nodes appear. Click one to see its retainer chain — this tells you exactly which variable is holding the reference.

Common causes:

• React refs to unmounted components — useRef value pointing to a DOM node after the component unmounts
• Cached DOM queries — const el = document.querySelector('.tooltip') stored in a module-level variable
• Event listeners on removed elements — The listener closure captures the element

The Three Snapshot Technique

Two snapshots can lie to you. Here's why: the first time you perform an action, your app might legitimately create persistent objects (caches warming up, lazy modules loading). Those look like leaks but aren't. Three snapshots give you the truth:

1. Snapshot 1: Baseline after app loads
2. Perform the suspect action once (open/close a panel). Snapshot 2.
3. Perform the same action again. Snapshot 3.

Compare Snapshot 3 against Snapshot 2. Objects that appear in Snapshot 2 vs 1 might be legitimate one-time allocations (caches, lazy initialization). But objects that appear again in Snapshot 3 vs 2 are leaked per-action — every repetition leaks more.

Allocation Timeline for Hot Spots

Sometimes you need to see allocations happening in real time rather than comparing static snapshots. The Allocation Instrumentation timeline shows a blue bar for each allocation. Over time, bars that survive GC stay blue; bars that are collected disappear. Super useful for pinpointing exactly when during a user flow things start leaking.

Steps:

1. Start Allocation Instrumentation recording
2. Perform the workflow slowly
3. Stop recording
4. Click on blue bars (surviving allocations) to see what objects were created at that moment
5. Correlate timing with user actions to pinpoint which action leaks