Memory in large apps

Memory that should leave

A single-page app can stay open for hours. It changes routes without restarting the JavaScript process, so route-owned listeners, timers, and cached data need an owner and a stopping point.

This lesson follows Allocation profiling. That lesson helps you find allocation churn. Here, the question is longer-lived: after a page leaves, did its resources and state leave too?

We will use small models first. Then we will turn them into a practical routine: clean up routes, bound caches, write a budget, and repeat a user flow in continuous integration.

Leaks across route changes

Start with one tiny bug. The function below models a page that registers a resize listener but never removes it. Calling it three times prints 3.

1const listeners = [];2 3function mountPage() {4  window.addEventListener("resize", () => {});5  listeners.push("resize");6}7 8mountPage();9mountPage();10mountPage();11console.log(listeners.length);

Line 1 makes an array so the model can show registrations. Line 4 records one resize listener. Lines 7 through 9 mount the page three times, and line 10 prints three registered listeners.

In a browser, window keeps a registered listener. The listener can keep its closure, and the closure can keep the old page state. A page can disappear from the screen while its data remains reachable.

The fix starts by writing down ownership. If the product route registers a resize listener, the product route owns its removal. A shared application listener belongs to the shared application shell instead. That small distinction prevents a route from deleting work it did not create.

1const page = createRouteModel(false);Run2 3for (let visit = 0; visit < 3; visit += 1) {4  page.mount();5  page.unmount();6}7 8console.log(page.counts());

Give each page cleanup

A route should remove what it registered. That normally means removeEventListener for listeners, clearInterval for intervals, and dropping app-owned arrays that store old page state.

1function mountPage(window) {2  const controller = new AbortController();3  const onResize = () => console.log("resize");4  window.addEventListener("resize", onResize, { signal: controller.signal });5  const timer = setInterval(() => console.log("refresh"), 1000);6 7  return () => {8    controller.abort();9    clearInterval(timer);10  };11}

Line 2 creates one AbortController. Line 4 attaches a listener to its signal. Line 5 starts an interval. Lines 7 through 10 return cleanup: abort removes signal-based listeners and clearInterval stops the timer.

One controller is useful when a page creates several event listeners. It does not clear an interval for you, so the cleanup still calls clearInterval. Keep the returned cleanup close to the code that mounted the route.

Cleanup should be safe to call more than once. A route can change quickly, an error boundary can replace a view, or a test can unmount a component early. The route model ignores a second unmount, which is a useful shape for cleanup code: after the first call, there is nothing left for the second call to remove.

1const page = createRouteModel(false);2 3for (let visit = 0; visit < 3; visit += 1) {4  page.mount();5  page.unmount();6}7 8console.log(page.counts());

Change only the visit count first. With cleanup off, all three counts grow together. Turn cleanup on and each mount/unmount pair returns its listener, timer, and saved page reference to zero.

Bounded caches with LRU

A cache is not automatically a leak. It is a deliberate trade: keep a result now so a later request can be faster. The important word is bounded: the cache must have a maximum size or another eviction rule.

1const cache = new LruCache(2);2cache.set("tea", "tea result");3cache.set("milk", "milk result");4cache.get("tea");5cache.set("bread", "bread result");6console.log(cache.keys().join(","));

Line 1 creates a two-item cache. Lines 2 and 3 add tea and milk. Line 4 reads tea, which refreshes its recent position. Line 5 adds bread and evicts milk, the least recently used key. Line 6 prints tea,bread.

A limit is not a random small number. Estimate the cost of a typical entry, choose how many useful recent results fit the devices you support, and then measure the real route. A limit of 500 can still be too large when each cached preview holds a large image or response.

1const cache = new LruCache(2);Run2cache.set("tea", "tea result");3cache.set("milk", "milk result");4cache.get("tea");5cache.set("bread", "bread result");6console.log(cache.keys().join(","));

1const cache = new LruCache(2);2cache.set("tea", "tea result");3cache.set("milk", "milk result");4cache.get("tea");5cache.set("bread", "bread result");6console.log(cache.keys().join(","));

WeakRef as an optional cache

A WeakRef is a reference that does not keep its target alive. It can help with a derived value that is cheap enough to recreate, but it is not a normal ownership tool and it is never a promise that a value stays present.

1const cache = new WeakMap();2 3function getPreview(product) {4  const saved = cache.get(product)?.deref();5  if (saved) return saved;6  const preview = makePreview(product);7  cache.set(product, new WeakRef(preview));8  return preview;9}

Line 5 asks the weak cache for a saved preview. Line 6 returns it only when it still exists. Lines 7 through 8 make and store a fresh preview when the weak value has already disappeared.

This is deliberately different from an LRU. An LRU promises its bounded entries until eviction. A weak cache may miss at any time after collection. That is why the fallback is the real feature, and the weak cache is only an optimization.

For everyday weak-key metadata, revisit WeakRef and finalization. For user-visible data such as an active cart, use a clear owner and explicit lifetime instead.

Set a memory budget

A memory budget turns “it seems to grow” into a check. For example: after ten visits to a product route, heap growth should be less than 8 MB. The number is a team decision based on the route, data, and devices you support.

1const beforeMB = 40;2const afterMB = 46.5;3const report = checkBudget(beforeMB, afterMB, 8);4console.log(report.passes, report.growthMB);

Line 1 records a before value of 40 MB. Line 2 records 46.5 MB after the flow. Line 3 compares growth against 8 MB. Line 4 prints true 6.5, because 6.5 MB is below the budget.

Do not choose a budget from one laptop run. Warm up the route, run the same flow several times, and set a threshold that leaves room for expected caches while catching steady growth.

Keep two questions separate. A route can have a healthy growth budget while a cache is still too large for a low-memory device. The budget checks the chosen flow; the cache limit checks one owner. Both are useful because they fail for different reasons.

Measure the right thing

DevTools is the usual first stop. Heap snapshots show retained objects and their retaining paths. Allocation profiling shows churn. Counts owned by your app can make a small route test very clear before you inspect a large heap.

1const samples = [12, 12, 12, 12];2const report = detectSteadyGrowth(samples);3console.log(report.leaking);

Line 1 supplies four equal samples. Line 2 checks whether every later run grows. Line 3 prints false, because a flat sequence is not steady growth in this model.

performance.memory is Chrome-only and deprecated, so do not build a product promise around it. In isolated pages, prefer measureUserAgentSpecificMemory() when available. It reports a browser-specific measurement, so compare repeatable trends instead of treating one number as universal truth.

Detect leaks in CI

Continuous integration can repeat a user flow after warm-up. Navigate to a route, interact, navigate away, and repeat. Then compare a stable count: app-owned listeners, route objects, or a browser query result.

Meta's MemLab is built for finding browser memory leaks across interactions. Puppeteer also has page.queryObjects, which can count objects for a prototype in a test browser. Both are tools for evidence, not shortcuts around understanding the retaining path.

1const samples = [12, 12, 12, 12];2const report = detectSteadyGrowth(samples);3console.log(report.leaking);

Use one warm-up run to load code and build expected caches. Then repeat the exact flow N times. Force garbage collection only in a controlled test browser when its test setup allows it; application code must not depend on that force.

A good failure message names the growing thing and the flow. “Product page listener count grew from 2 to 12 after ten visits” gives a developer a starting point. “Heap changed” does not.

Run the flow in a stable browser and keep the action small. For example, visit the products route, open one item, return to the list, and repeat. A test that changes its own data, network timing, and route sequence on every run cannot tell you whether memory changed because of the code or because the experiment changed.

A stable collection check

Runtime evidence can test a small reachability claim without asserting a heap size or timing. In a Node child process started with --expose-gc, the model mounts then unmounts two pages and keeps WeakRefs to their state.

1const later = () => new Promise((resolve) => setTimeout(resolve, 0));2const livePages = [];3 4function mount(cleanup) {5  let page = { title: "products", items: new Array(1000).fill("tea") };6  const weak = new WeakRef(page);7  const retainedPage = page;8  const listener = () => retainedPage.items.length;9  livePages.push(listener);10  const unmount = () => {11    if (cleanup) livePages.pop();12    page = null;13  };14  return { weak, unmount };15}16 17async function collect(weak) {18  for (let attempt = 0; attempt < 10; attempt += 1) {19    await later();20    globalThis.gc();21    await later();22    if (weak.deref() === undefined) return true;23  }24  return false;25}26 27let leaky = mount(false);28const leakyWeak = leaky.weak;29leaky.unmount();30leaky = null;31let clean = mount(true);32const cleanWeak = clean.weak;33clean.unmount();34clean = null;35console.log("leaky alive", leakyWeak.deref() !== undefined);36console.log("clean collected", await collect(cleanWeak));

Line 7 stores a listener in a global model list. Line 9 removes it only in the cleaned-up case. Line 11 clears the local page reference. The final lines show the leaky page remains alive while the cleaned-up page can be collected after later tasks.

A practical review routine

Review one route at a time. Write down what it registers, what it caches, and who cleans each thing. A local cleanup function is easier to verify than an undocumented global convention.

• Pair every event listener, observer, and interval with route cleanup.
• Give every long-lived cache a size limit, expiry rule, or explicit owner.
• Use heap snapshots to find the retaining path before changing code.
• Warm up and repeat a real flow before declaring a leak.
• Put the memory budget beside the route test, not in a forgotten document.

Cancellation is often cleanup too. When a route owns an in-flight request, use AbortController cancellation so work and callbacks do not continue after the route changed.

Common misconceptions

• “GC means routes cannot leak.” A host listener, timer, or global cache can still make old state reachable.
• “WeakRef removes cleanup work.” Cleanup removes your references. WeakRef only permits collection of a cache value.
• “An LRU limit is always safe.” The limit must still fit the route and the devices you support.
• “One before-and-after heap number proves a leak.” Warm-up and collection timing add noise; look for repeated growth and retaining paths.

Practice exercises

const listeners = [];

function mountPage() {
  window.addEventListener("resize", () => {});
  listeners.push("resize");
}

mountPage();
mountPage();
mountPage();
console.log(listeners.length);

clearInterval(timer);

const cache = new LruCache(2);
cache.set("tea", 1);
cache.set("milk", 2);
cache.get("tea");
cache.set("bread", 3);
console.log(cache.keys().join(","));

const beforeMB = 40;
const afterMB = 46.5;
const report = checkBudget(beforeMB, afterMB, 8);
console.log(report.passes, report.growthMB);

Check your understanding

Use the same order as a real investigation: identify the owner, check cleanup, check the cache bound, then look for a repeatable growth signal.

Key takeaways

• Route changes do not restart the JavaScript process, so routes must release what they register.
• Listeners, intervals, and global arrays can retain an old page through an accidental reference path.
• LRU caches need a real bound; WeakRef caches need a real fallback.
• Memory budgets compare repeatable growth after warm-up, not one noisy heap number.
• CI can repeat user flows and compare stable counts or browser memory evidence.

Coming next: Memory in Node.js, where heap limits, external memory, Buffers, and out-of-memory failures matter on the server.