Memory Leaks and Performance Over Time

The plain-language idea

Everything else in this track is about a single moment: a slow first paint, a slow response to one click, a layout shift on one load. A memory leak breaks that framing — it's not about any single moment being slow, it's about a long-lived single-page-application session getting progressively slower and more janky the longer it stays open. A dashboard that feels snappy when a user opens it in the morning and noticeably sluggish by the afternoon, with no single code change in between, is the signature symptom.

The mechanism (covered in the JavaScript track's garbage collection lesson) is reachability: JavaScript keeps anything still reachable from a live reference, and frees anything that isn't. A leak is something staying reachable longer than intended. What that means for a long session specifically is that the pool of "reachable but never actually needed again" memory keeps growing, and the garbage collector has to work harder against a bigger and bigger live set every time it runs, which itself becomes a source of jank — a GC pause that stalls the main thread mid-interaction.

See it in a real thing: three common SPA leak sources

// 1. Listener on a long-lived target, never removed
function ChatPanel() {
  useEffect(() => {
    window.addEventListener("resize", handleResize);
    // missing: return () => window.removeEventListener("resize", handleResize);
  }, []);
}

// 2. Interval that outlives the component that started it
function LiveTicker() {
  useEffect(() => {
    setInterval(fetchLatestPrice, 1000);
    // missing: clearInterval cleanup on unmount
  }, []);
}

// 3. A closure capturing more than it uses
function attachHandler(hugeDataset) {
  const total = hugeDataset.length;              // only this is needed
  button.addEventListener("click", () => {
    console.log(total);
  });
  // the closure's enclosing scope still holds a live reference to
  // hugeDataset itself, keeping the whole dataset reachable
}

All three share the same shape: something outlives the component or moment that created it, and stays reachable through a reference nothing is actively using anymore. In a page that loads once and reloads on navigation, this barely matters — the whole heap gets thrown away. In a long-lived SPA session where components mount and unmount hundreds of times without a full page reload, each unreleased listener, interval, or over-captured closure is one more thing pinned in memory for the rest of the session.

What people usually miss

Watch out

• The real diagnostic tool is a heap snapshot diff, not code review. Open DevTools' Memory panel, force a garbage collection (the trash-can icon), take a heap snapshot, interact with the app for a while doing something that should be memory-neutral (open and close a panel repeatedly, say), force GC again, take a second snapshot, then compare — anything still retained that should have been freed is your leak, and DevTools shows exactly what's still holding a reference to it.
• A growing memory number alone isn't proof of a leak. Memory usage naturally fluctuates as the app does work; the real signal is memory that keeps climbing across a repeated, supposedly-neutral action and never comes back down after GC runs.
• "It's slow after being open a while" is a different bug report than "it's slow on load," and needs a different investigation. The first points at accumulation over time (a leak); the second points at a single expensive operation — chasing the wrong one wastes real time.
• setInterval is an easy one to miss because the bug is an omission, not a mistake in the code that's there. There's no wrong line to spot — the bug is the missing clearInterval in the cleanup path, which only shows up as absence.

Why this matters in interviews

"A long-running dashboard gets slower the longer it's left open — how would you track that down?" is a real, practical question, and describing the two-snapshot heap comparison workflow (not just naming "memory leak" as the diagnosis) is what shows you can actually find one, not just recognize the symptom.