Browser memory leak detection
Slap yourself if
You think memory leaks are just ‘forgot to remove an event listener’.
Why this exists
Browser memory leaks exist because garbage collection only frees unreachable objects. Modern UIs create long-lived references across closures, DOM, caches, workers, and async lifecycles that quietly keep memory alive long after intent has ended.
Mental model
A memory leak is not extra memory usage — it’s a reference graph that never collapses. If something is still reachable, the GC is doing its job by not freeing it.
- Objects become unreachable only when no live references remain.
- Closures, DOM nodes, timers, and caches often outlive their usefulness.
- The browser GC frees memory opportunistically, not immediately.
- Leaks manifest as retained object graphs, not constant growth alone.
- Detached DOM nodes retained by JS references.
- Closures capturing large objects unintentionally.
- Global caches without eviction policies.
- Async work completing after lifecycle teardown.
Browser memory leak detection is about identifying objects that remain reachable when they should not be, typically via retained references across DOM, closures, or async lifecycles.
- Memory usage only ever goes up after navigation
- Detached DOM nodes in heap snapshots
- Long-lived singletons holding UI references
- Assuming GC timing equals correctness
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.