Fixing JavaScript Memory Leaks

What a leak is, and what it is not

JavaScript frees memory automatically. The garbage collector periodically looks for objects that nothing can reach any more and reclaims them. A leak is therefore not memory the browser forgot; it is memory your code can still reach, usually by accident. An array that keeps growing, a listener on window that refers to a removed component, or a timer that still runs after its view has gone all keep their objects reachable, so none of it is collected.

Some patterns look like leaks but are not:

• A saw-tooth graph. Memory rising while you use the page and then dropping sharply is the collector doing its job.
• One-off growth. Memory that rises on the first visit to a route and then stays flat is usually a cache or code being loaded once.
• Large but stable. A page that uses a lot of memory but does not grow with use has a size problem, not a leak.

The signature of a leak is growth that repeats: do the same action ten times and memory climbs roughly ten steps, and a forced garbage collection does not bring it back down.

The usual causes

Closures are the thread running through all of these. A small function captures the variables around it, so a listener that only needs a number can end up holding an entire component, its data and its DOM.

Measuring memory over time

Start with a quick overview before using heap snapshots, which are slower.

The Performance panel with memory counters

Open DevTools, go to Performance, tick the Memory checkbox and start recording. Perform your journey several times, for example open and close a product quick-view ten times, click the bin icon to force garbage collection, then stop. The graph shows the JavaScript heap along with counts of DOM nodes and event listeners. If the heap, node count or listener count ends much higher than it started after the forced collection, and each repetition adds a similar step, you have a leak in that journey.

Chrome Task Manager

From the Chrome menu, open More tools, Task manager (Shift+Esc on Windows). Right-click the column headers to add JavaScript memory. Leave the page open while you repeat the journey and watch whether the figure keeps rising. This is useful for checking a long session without DevTools open.

Reading heap snapshots

A heap snapshot records every object in the page's JavaScript memory and what refers to what. Taking a snapshot forces garbage collection first, so what remains is genuinely reachable.

1. In the Memory panel choose Heap snapshot and take one on the starting screen. This is your baseline.
2. Perform the journey once, return to the starting screen and take a second snapshot. This includes one-off growth such as caches and lazily loaded code.
3. Repeat the journey several more times, return to the starting screen and take a third snapshot.
4. Select the third snapshot and switch the view from Summary to Comparison against the second. Sort by the delta or size delta column.

Objects whose count grows by roughly the number of times you repeated the journey are your leak. Typing Detached in the class filter shows DOM elements that are no longer in the page but are still held in memory; recent Chrome versions also offer a dedicated detached elements profile in the Memory panel.

Select any suspect object and look at the Retainers pane underneath. It shows the chain of references keeping the object alive, ending at a root such as Window. Somewhere in that chain is a property name, array or closure variable from your own code, and that is the line to change.

The fix, step by step

A clean-up pattern that works anywhere

This plain JavaScript component adds listeners, an observer and a timer, and removes all of them in one place. The same structure fits any framework's mount and unmount hooks.

export function mountStockTicker(root) {
  const controller = new AbortController();
  const { signal } = controller;

  const handleResize = () => layout(root);
  window.addEventListener('resize', handleResize, { signal });
  root.querySelector('.refresh').addEventListener('click', refresh, { signal });

  const observer = new IntersectionObserver(entries => {
    if (entries[0].isIntersecting) refresh();
  });
  observer.observe(root);

  const timer = setInterval(refresh, 30000);

  async function refresh() {
    const res = await fetch('/api/stock', { signal }).catch(() => null);
    if (res) render(root, await res.json());
  }

  // Call this when the component is removed.
  return function unmount() {
    controller.abort();      // removes both listeners and cancels fetches
    observer.disconnect();
    clearInterval(timer);
  };
}

The key point is that the function which sets things up also returns the function that tears them down, so the two cannot drift apart.

Framework and library notes

• React. Return a clean-up function from each effect that adds listeners, timers or subscriptions. The React and Next.js guide covers effect clean-up in detail.
• Vue. Remove global listeners and timers in onUnmounted (or beforeUnmount); listeners added with Vue's template syntax are removed for you.
• Angular. Unsubscribe from observables, typically by completing a subject in ngOnDestroy or using the operators designed for automatic clean-up.
• jQuery-era code. Removing elements with jQuery's own methods clears the data and handlers it stored; removing them with plain DOM methods may not.
• Maps, charts and editors. Most have a destroy(), remove() or dispose() method. Call it before the container is removed.

Preventing leaks

• Pair every setup with a teardown in code review: each addEventListener, setInterval, observer and subscription should have a matching clean-up line.
• Prefer listeners on the component's own element rather than on window, since they go when the element goes.
• Bound every cache when you create it, not when it causes trouble.
• Automate a soak test for your busiest journeys and track heap size over releases.
• Test on a phone. Phones have far less memory to spare, so leaks that are invisible on a desktop show up there first.