When memory never comes back
A memory leak happens when a page keeps references to objects it no longer needs, so the garbage collector cannot reclaim them. In a long lived single page app this memory grows over time, eventually making the tab sluggish or crashing it. Detecting leaks means watching memory across repeated actions.
- Memory should return to a baseline after a repeated action.
- A steady upward trend across cycles signals a leak.
- Leaks hurt most in apps the user keeps open for hours.
Common sources
A few patterns cause most front end leaks.
- Forgotten listeners keep handlers and their scope alive.
- Detached nodes are removed from the page but still referenced by script.
- Growing caches store entries that are never evicted.
- Timers that are never cleared hold their closures forever.
A detection workflow
- Record a baseline, perform an action several times, and compare heap snapshots.
- Look for objects whose count climbs with each cycle.
- Trace the retaining path to find what still references them.
Fixing leaks
- Remove listeners when a component unmounts.
- Clear intervals and timeouts you started.
- Bound caches with a size limit or weak references.
Key idea
A memory leak is retained objects the collector cannot free, so detect it by watching the heap grow across cycles and fix it by releasing listeners, timers, and unbounded caches.