Why Detached DOM Nodes Persist After Unmount

When a React component unmounts, the DOM nodes are removed from the document, but they aren't necessarily garbage collected. If event listeners, timers, or closures still hold references to those nodes, the entire component tree remains in memory. This is the most common source of React memory leaks. Chrome DevTools heap snapshots expose these as "Detached HTMLDivElement" entries with significant retained size. The classic pattern involves mounting a component that registers a global event listener without cleanup. Each mount-unmount cycle leaks the full component tree because the event handler closure captures the component's scope.

Heap Snapshot Comparison

Memory Leak Detection Pattern:

// Leaky pattern - no cleanup
useEffect(() => {
  const handler = (e) => {
    // Closure captures component scope
    console.log(componentState);
  };
  document.addEventListener('click', handler);
  // Missing: return () => document.removeEventListener('click', handler);
}, []);

// Correct pattern - cleanup prevents leak
useEffect(() => {
  const handler = (e) => { /* ... */ };
  document.addEventListener('click', handler);
  return () => document.removeEventListener('click', handler);
}, []);

Take heap snapshots before mounting, after mounting, and after unmounting. If memory doesn't decrease post-unmount, you have a leak. Filter snapshots by "Detached" to isolate orphaned DOM nodes and trace their retainers.

Shallow vs Retained Size Reveals True Impact

An object's shallow size only reflects its direct memory footprint, which can be misleadingly small. A Redux store object might occupy just 100 bytes, but its retained size includes everything it references like the entire application state tree at 50MB. When debugging leaks, always sort heap snapshots by retained size, not shallow. A tiny listener callback with 50 bytes shallow size can retain a 10MB React fiber tree. The "Retainers" view exposes the reference chain keeping objects alive. Watch for global event emitters holding component references, memoized selectors capturing large state slices, and third-party libraries with hidden internal caches that accumulate component references.

When Memory Leaks Actually Matter

Not all memory leaks require immediate attention. A component that leaks 500KB but only mounts once per session is negligible, but the same leak in a list item rendered 1000 times consumes 500MB and degrades performance. Prioritize leaks in high-frequency components like modals, dropdown menus, table rows, and route transitions. Monitor heap size growth rate, not absolute values. If memory climbs 10MB per hour during normal usage, users on 8-hour sessions will hit 80MB growth, potentially triggering tab crashes on lower-end devices. The critical threshold is when leaked memory exceeds available device RAM or causes full garbage collection pauses above 100ms, which users perceive as jank.

Production Monitoring Strategy

Instrument production apps with "performance.memory.usedJSHeapSize" tracking at key user journey milestones like route changes and major interactions. Sample 1-5% of users to avoid performance overhead. Set up alerts when heap size grows beyond expected baselines for specific workflows. For example, if navigating between 10 product pages typically increases heap by 15MB but suddenly grows to 45MB, investigate recent deployments. Use Error Monitoring tools to capture heap snapshots when users report sluggishness. Track correlation between session duration and crash rates, if crashes spike after 30 minutes of usage, you likely have an accumulating leak in frequently used features.