Memory in large apps

Memory that should leave

A single-page app is a website that loads once and then swaps pages without reloading. Gmail and most online shops work like this. Each of these inner pages is called a route, such as /products or /settings.

The app can stay open for hours. When you move to a new route, the JavaScript keeps running; nothing starts fresh. So anything a route starts must also be stopped by that route. That includes:

• listeners: functions that run when something happens, such as the window being resized,
• timers: functions that run again every few seconds,
• saved data: lists and caches that hold the route's values.

This lesson comes after Allocation profiling. That lesson showed how to find code that makes many short-lived objects. This lesson asks a different question: when a page leaves the screen, does its memory leave too?

We start with small models. Then we build a routine you can use on a real app:

1. Clean up each route when it leaves.
2. Give each cache a size limit.
3. Write down how much memory may grow.
4. Repeat a user's steps in an automatic test.

Leaks across route changes

Start with one tiny bug. The function mountPage stands for showing a page. To mount a page means to put it on the screen; to unmount it means to take it off.

Each time mountPage runs, it adds a resize listener. It never removes one. 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 by line:

1. Line 1 makes an empty array, listeners. We use it to count the listeners we add.
2. Line 4 asks the browser to call a function each time the window is resized.
3. Line 5 writes "resize" into the array, so we can count it.
4. Lines 8 to 10 show the page three times.
5. Line 11 prints 3: three listeners, and none were removed.

In a real browser, window keeps every listener you add until you remove it. A listener is a function, and a function can still use the variables around it where it was written. This is called a closure. So the listener can keep the old page's data alive.

The fix starts by writing down who owns each thing: who started it, and so who must stop it. If the product route adds a resize listener, the product route must remove it. A listener the whole app shares belongs to the whole app instead. Then a route never removes something it did not start.

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 undo what it started. Usually that means:

• removeEventListener for each listener,
• clearInterval for each repeating timer,
• emptying any app list that still holds the old page's data.

The code below uses an AbortController. It is a small object with a signal and an abort() method. When you add a listener with that signal, calling abort() removes the listener for you.

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 by line:

1. Line 2 makes one AbortController.
2. Line 4 adds the resize listener and ties it to the controller's signal.
3. Line 5 starts a timer that runs every second. setInterval gives back an id, saved in timer.
4. Lines 7 to 10 give back a cleanup function. The app calls it when the page leaves.
5. Line 8, controller.abort(), removes the listener.
6. Line 9, clearInterval(timer), stops the timer.

One controller helps when a page adds several listeners: one abort() removes them all. But it does not know about the timer. So the cleanup still calls clearInterval. Keep the cleanup code right next to the code that started things.

Calling cleanup twice should be safe. Routes can change quickly, an error screen can replace a page, or a test can take a page off early. In our route model, a second unmount does nothing. That is a good habit for cleanup code: after the first call, there is nothing left 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());

First, change only the number of visits. With cleanup off, all three counts grow together. Then turn cleanup on. Now every visit removes its listener, timer, and saved page, so each count goes back to zero.

Caches with a size limit (LRU)

A cache saves a result so the next request for it is faster. A cache is not a leak by itself. It is a trade: you spend memory to save time.

The important part is a limit. A cache must have a largest size, or another rule that removes old entries. Removing an entry to make room is called evicting it.

An LRU cache ("least recently used") evicts the entry that nobody has used for the longest time. The lesson's LruCache keeps its entries in a Map. A Map remembers the order keys were added: the first key is the oldest, the last key is the newest.

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 by line:

1. Line 1 makes a cache that holds at most two items.
2. Lines 2 and 3 add tea, then milk. Now the cache is full.
3. Line 4 reads tea. A read moves the key to the newest place, so milk is now the oldest.
4. Line 5 adds bread. That makes three, so the cache evicts the oldest key, milk.
5. Line 6 prints the keys, oldest first: tea,bread.

Do not pick a limit at random. Work it out in three steps:

1. Guess how much memory one entry uses.
2. Choose how many recent entries fit on the slowest phones you support.
3. Measure the real route.

A limit of 500 can still be too big. For example, each saved preview might hold a large image.

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(","));

A WeakRef cache can lose its value

A WeakRef points to an object without keeping it alive. The garbage collector may still free the object. Its deref() method gives back the object, or undefined if the object is already gone.

A WeakRef can help with a value that is cheap to make again, such as a small preview. It does not decide who owns a value. And it never promises the value is still there.

The code below also uses a WeakMap: a Map whose keys are objects and does not keep those keys alive.

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 by line:

1. Line 1 makes the cache: a WeakMap from each product to a WeakRef of its preview.
2. Line 4 looks up the product's WeakRef and calls deref(). The ?. gives undefined if there is no WeakRef yet.
3. Line 5 returns the saved preview if it still exists.
4. Lines 6 and 7 make a fresh preview and save a new WeakRef to it.
5. Line 8 returns the fresh preview.

This works differently from an LRU cache. An LRU cache keeps its entries until it evicts them. A WeakRef cache can lose a value at any time after the garbage collector runs. So the code that makes the value again (lines 6 to 8) is what your app really depends on. The WeakRef only saves time when it gets lucky.

The table compares four ways to keep values. Read one row at a time.

For more on WeakRef and WeakMap, see WeakRef and finalization. For data the user can see, such as their shopping cart, do not use a weak cache. Give it a clear owner and remove it on purpose.

Set a memory budget

A memory budget turns "memory seems to grow" into a check that passes or fails. For example: after ten visits to the product route, memory may grow by less than 8 MB (megabytes). Your team picks the number, based on the route, its data, and the devices you support.

The memory we measure here is the heap: the area where JavaScript keeps objects, arrays, and functions.

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

Line by line:

1. Line 1 saves the memory before the flow: 40 MB.
2. Line 2 saves the memory after the flow: 46.5 MB.
3. Line 3 works out the growth, 46.5 − 40 = 6.5 MB, and checks if it is less than 8 MB.
4. Line 4 prints true 6.5: the check passes, and the growth was 6.5 MB.

Do not choose a budget from one run on your own laptop. Instead:

1. Warm up: visit the route once first, so code and expected caches are loaded.
2. Run the same steps several times.
3. Pick a limit with room for expected caches, but low enough to catch memory that grows on every run.

Keep two questions apart. A route can stay inside its budget while one cache is still too big for a phone with little memory. The budget checks a whole flow. The cache limit checks one cache. You need both, because they catch different problems.

Measure the right thing

Browser DevTools is the usual place to start. It gives you two useful tools:

• A heap snapshot lists every object in memory. For each one it shows the retaining path: the chain of references that keeps it alive.
• Allocation profiling shows code that makes many short-lived objects.

Before you open a big snapshot, a simple count can help. Count things your own app adds, such as listeners, and check the count after each visit.

The helper detectSteadyGrowth takes a list of memory numbers, one per run. It says leaking: true only if memory grew on every single run.

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

Line by line:

1. Line 1 gives four runs, each at 12 MB.
2. Line 2 checks if every run grew from the one before.
3. Line 3 prints false. Memory stayed flat, so it did not grow on every run.

Browsers also have memory numbers you can read from code. Be careful with them:

• performance.memory works only in Chrome and is deprecated (old, and may be removed). Do not build your product checks on it.
• measureUserAgentSpecificMemory() is the newer one. It works only on HTTPS pages that are cross-origin isolated (a special security mode set by response headers), and only in some browsers.

Each browser measures memory in its own way. So compare the trend over many runs, not one number.

The table lists four memory signals. For each one, it says which tool gives it and what a healthy result looks like.

Catch leaks in automatic tests

CI (continuous integration) is a server that runs your tests every time someone changes the code. A CI test can act like a user, again and again:

1. Open a route.
2. Click around.
3. Leave the route.
4. Repeat.

Then it compares a number that should stay steady, such as the number of listeners your app added, the number of page objects, or a count from the test browser.

Two tools help with this:

• MemLab, from Meta, repeats clicks in a browser and looks for objects that should have been freed.
• Puppeteer controls a test browser from code. Its page.queryObjects finds every object made from one prototype, such as every object made by a Page class, so the test can count them.

Both tools give you evidence. You still need to find the retaining path to know what to fix.

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

This is the same check as before. In CI, run the flow once to warm up, so code is loaded and expected caches are built. Then repeat the exact same flow a set number of times and pass the numbers to the check.

Some test browsers let a test force the garbage collector to run. Do that only inside the test. Your app's own code must never depend on it.

When the test fails, the message should say what grew and during which steps. "Product page listener count grew from 2 to 12 after 10 visits" tells a developer where to look. "Memory changed" does not.

Keep the steps small and the same on every run. For example: open the products route, open one item, go back to the list, and repeat. If the data, network speed, or steps change on every run, you cannot tell whether memory changed because of the code or because the test changed.

A test that proves cleanup frees the page

We can also test one small fact directly: after cleanup, can the old page be freed? This test does not check memory sizes or timing.

It runs in Node.js, in a separate child process (a second Node program started just for the test). The child starts with the --expose-gc flag. That flag adds a gc() function that runs the garbage collector on demand.

The test shows two pages and then takes both off: one without cleanup, one with cleanup. It keeps a WeakRef to each page, so it can check later if the page is gone.

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));

The important lines:

• Line 5 makes the page's data: a title and 1,000 items.
• Line 9 adds the page's listener to the shared livePages list. The listener uses the page data, so it keeps the page alive.
• Line 11 removes that listener, but only for the page with cleanup.
• Line 12 sets the local page variable to null.
• Line 35 prints leaky alive true: the page without cleanup is still in memory.
• Line 36 prints clean collected true: after a few rounds of gc(), the cleaned-up page is gone.

A routine for checking a real app

Check one route at a time. Write down three things: what it adds (listeners, timers), what it saves (caches), and who cleans up each one. A cleanup function next to the code is easier to check than a rule nobody wrote down.

• Give every listener, observer, and timer a matching cleanup step.
• Give every cache that lives a long time a size limit, an expiry time, or a clear owner.
• Use a heap snapshot to find the retaining path before you change code.
• Warm up, then repeat the real steps, before you call something a leak.
• Keep the memory budget next to the route's test, not in a document nobody reads.

Stopping a request is cleanup too. If a route starts a network request that has not finished, use AbortController cancellation to stop it. Then its code does not keep running after the user has left.

Common misconceptions

• "JavaScript frees memory for me, so routes cannot leak." The garbage collector frees only what nothing points to. A listener, timer, or global cache can still point to the old page.
• "A WeakRef means I don't need cleanup." Cleanup removes your own references. A WeakRef only lets one cached value be freed.
• "An LRU limit is always safe." The limit must still be small enough for the route and the phones you support.
• "One before-and-after memory number proves a leak." Warm-up and garbage collector timing change the numbers. Look for growth on every run, and find the retaining path.

The table puts each wrong idea next to a better one. Read across each row.

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

Answer in the same order you would check a real app:

1. Who started this thing?
2. Does cleanup undo it?
3. Does the cache have a limit?
4. Does memory grow on every repeat?

Key takeaways

• Changing routes does not restart JavaScript. So each route must undo what it started.
• A listener, timer, or global list can keep an old page in memory by mistake.
• An LRU cache needs a real size limit. A WeakRef cache needs code that makes the value again when it is gone.
• A memory budget checks growth over repeated runs after a warm-up, not one memory number.
• A CI test can repeat a user's steps and check that counts or memory do not grow on every run.

Coming next: Memory in Node.js. On a server, you meet new limits: the heap size limit, memory outside the heap, Buffers, and what happens when memory runs out.