Browser Memory Management
A long-lived web application that grows slower the longer it runs usually has one cause: it is holding on to memory it no longer needs. Browser memory management is how the JavaScript engine allocates memory for your objects and reclaims it when they are no longer used, and understanding it is what lets you avoid the leaks that degrade single page applications over time. This page defines the concept and the leak patterns that matter; the practical fix for view leaks appears in the SPA routing example.
The aim is a working understanding of the term and its failure modes, not engine internals.
What you'll learn
What memory management is
Every object your code creates lives somewhere, and something has to clean up.
A definition
Browser memory management is the automatic process by which the JavaScript engine reserves memory when you create objects, variables, and DOM nodes, and frees it once they are no longer reachable. You do not allocate or release memory by hand as in some languages; the engine does it for you, which is convenient but not foolproof.
How garbage collection works
The engine decides what to free using a simple principle of reachability.
Reachability and collection
The garbage collector periodically finds every object still reachable from your running code, by following references from a set of roots, and frees everything else. An object referenced by a variable in scope, or by another reachable object, is kept; one that nothing can reach is collected. The implication is direct: memory is freed only when nothing references it, so an unwanted reference keeps memory alive.
What a memory leak is
A leak is not the engine failing; it is your code keeping references it should have dropped.
The definition of a leak
A memory leak in the browser is memory that is no longer needed but cannot be collected because something still references it. The application keeps using more memory, and over a long session it slows down or crashes a tab. Because collection is based on reachability, every leak traces back to a reference that was never released.
Common leak patterns
A few patterns cause the large majority of frontend leaks.
Where leaks come from
The most common are detached DOM nodes, elements removed from the page but still referenced by a variable, so they cannot be freed; lingering event listeners that keep their target and surrounding scope alive; and timers or subscriptions that are never cleared. These are exactly the hazards the view-disposal pattern in the SPA routing example and the event-driven UI example are designed to prevent.
How to avoid leaks
Avoiding leaks is mostly a discipline of releasing what you no longer need.
Releasing references
Remove event listeners when a component goes away, clear timers and intervals, and drop references to DOM nodes once they leave the page. Frameworks help by tying cleanup to a component lifecycle, which is why Backbone provides methods that stop listening when a view is removed. The browser Performance and Memory tools, described in the browser DevTools guide, let you confirm memory is actually being reclaimed.
A common misconception
One assumption lulls developers into ignoring memory entirely.
Automatic does not mean leak-proof
Because collection is automatic, it is tempting to assume leaks are impossible in the browser. They are not. The engine frees only what is unreachable, so code that unintentionally keeps references, through a forgotten listener or a closure, leaks despite the collector. Automatic memory management removes manual freeing, not the need to think about what you hold on to. The performance impact connects to DOM rendering performance.
Frequently Asked Questions
What is browser memory management?
It is the automatic process by which the JavaScript engine reserves memory when you create objects and DOM nodes, and frees it once they are no longer reachable from running code. You do not allocate or release memory by hand.
What causes memory leaks in web apps?
Most leaks come from detached DOM nodes still referenced by a variable, event listeners that are never removed, and timers or subscriptions that are never cleared. Each keeps memory reachable so it cannot be collected.
How does garbage collection work in JavaScript?
The collector periodically finds every object still reachable from a set of roots by following references, and frees everything else. An object nothing can reach is collected, so an unwanted reference keeps memory alive.
Can JavaScript have memory leaks if collection is automatic?
Yes. The engine only frees what is unreachable, so code that unintentionally keeps references, through a forgotten listener or a closure, leaks despite automatic collection. Automatic management removes manual freeing, not the need to release references.
Read next: the MVC pattern, or the Concepts hub.
See leaks fixed in code?
The SPA routing example shows view disposal that keeps memory flat.
Read: SPA Routing Example →