Chrome Heap Snapshots: Why a Small Object Has a Large Retained Size
A tiny object in your heap snapshot still shows a huge retained size after you close its view. What is it keeping alive, and how do you follow the trail?
- A small object can retain much more memory by keeping other objects reachable.
- In a constructor group, Shallow Size is a sum; Retained Size is a maximum.
- Compare snapshots taken before and after an operation and its reversal, then follow the references to objects that should have been released.
A small object can keep a large allocation alive
Shallow size measures the object itself. Retained size measures memory that could be reclaimed with it. The latter includes dependent objects that would become unreachable. A small object can therefore have a large retained size, as explained in Chrome's memory terminology guide.
Do not simply add everything reachable from that object. Memory still reachable through another live path would not be freed with it. Nor does a high retained size establish a leak: the application may still need the data.
| Row | Shallow Size | Retained Size |
|---|---|---|
| One object | Its own size. | Memory reclaimable with it. |
| Constructor group | Sum across the objects. | Maximum among the objects. |
The Summary documentation specifies different aggregation rules for the columns. Expand a group before reasoning about an individual instance.
Compare snapshots before and after opening and closing a view
Take a snapshot under Memory → Heap snapshot. Perform the suspected operation and reverse it a few times, then capture another snapshot. Use Comparison against the first capture to investigate unexpected survivors. Opening and closing a document is the official guide's example.
For a web app, apply that pattern to the same view-opening and closing sequence. Snapshot capture starts with garbage collection, so the result is not a record of every temporary allocation that preceded it.
Removing a DOM node does not remove every reference
The bottom Retainers section identifies objects pointing to your selection. For a detached DOM investigation, enter Detached in the class filter and inspect the code retaining nodes that the page no longer needs.
JavaScript can keep a removed node alive. Fix the unnecessary reference, then repeat the comparison. Also keep the measurement clean: Chrome's terminology guide recommends clearing Console and avoiding active debugger breakpoints because those tools can retain objects themselves.
Filter the references before deciding what to fix
The Memory improvements in Chrome 153 and 154 add minimum retained-size filtering for snapshot edges, exclusion of primitive values, and sorting by size or name. DevTools can also report memory retained by V8 execution contexts.
These controls help reduce a crowded reference view. They do not decide whether the retained data is still useful. Use size to narrow the candidates, comparison to identify unwanted survivors, and references to locate the cleanup that is missing.