Frontend Soak Testing

01Use a real browser

Everything this methodology looks for lives in the client: the retained DOM subtree, the listener that was never removed, the interval still ticking after its component was destroyed. None of it is visible from outside the browser.

HTTP level load testing tools send requests and read responses, and they're very good at it. A DOM, a framework reconciler, and a JavaScript heap that can grow are all outside what they do. A frontend soak test needs a real browser engine running the real application bundle, with real rendering and real garbage collection, because that's the only place these failures happen.

It also has to be a browser you can inspect from the outside. The most useful client side counters come from browser instrumentation, which in Chromium means the DevTools Protocol, so the engine you pick decides which signals you can collect at all.

02Keep the same session alive

Of the ten steps here, I think this is the one teams break by accident most often.

The browser, the page, and the application lifecycle all stay alive across every iteration. Reusing the browser between tests isn't enough. It has to be the same page, never reloaded and never navigated away from, from the first iteration to the last.

03Define a realistic user journey

The journey is the unit of pressure. It wants to be something a real person actually does over and over, and it wants to end where it started.

A journey that finishes in the state it began in gives you a clean expectation: the counts at the end of iteration 500 should look like the counts at the end of iteration 5, and any difference is something the app didn't clean up. A journey that builds up on purpose, like an infinite scroll feed or an append only log view, has no such expectation, so growth there tells you nothing.

• Navigating between routes and back again
• Opening and closing dialogs, drawers, and sheets
• Mounting and unmounting a component
• Creating a record, then deleting it
• Switching tabs and returning to the first
• Updating a chart with new data
• Opening and closing a document in an editor
• Applying a table filter, then clearing it
• Resizing a panel and restoring it
• Opening a menu and dismissing it
• Subscribing to a data source and unsubscribing
• Connecting a real time resource and disconnecting it

Journeys that cross a lifecycle boundary work best. Mounting and unmounting, subscribing and unsubscribing, connecting and disconnecting: these are the moments when cleanup code either runs or doesn't. A journey that only reads state, without creating and destroying anything, won't exercise much worth measuring.

04Repeat the lifecycle

The journey runs hundreds or thousands of times, back to back, in the same session. The point is cumulative lifecycle pressure: enough repetitions that a few kilobytes or a single listener per iteration turns into a trend you can't miss.

There's no universal number. It depends on how much one iteration does, and how small a leak you want to be able to see. One leaked listener per iteration shows up almost immediately. A leak of 2 KB per iteration needs enough repetitions to rise above the noise floor of ordinary heap movement, which usually means hundreds at minimum.

Iterations run as fast as the application accepts them. Waiting for animations, arbitrary sleeps, and real network round trips all slow the run down for nothing. Waiting on conditions instead of durations helps, and so does stubbing the network wherever the response content isn't what you're testing.

05Accelerate time

Rapid iteration compresses the usage that comes from interaction. Usage that comes from time passing is a separate problem. An application that polls every thirty seconds doesn't care how fast you click, because it needs thirty seconds to pass before it does anything.

Playwright's Clock API replaces the browser's time functions with controllable equivalents, so the test decides when time moves.

// Installed before the application loads, so it never sees the real clock.
await page.clock.install();
await page.goto('/dashboard');

// Time now stands still until the test moves it.
await page.clock.pauseAt(new Date('2026-01-01T09:00:00Z'));

// Moves 30 seconds of application time, firing every timer that falls due.
await page.clock.runFor(30_000);

runFor() moves the clock forward through the interval and fires the timers that fall due along the way. fastForward() jumps ahead instead, firing due timers at most once, which is what you want for skipping a long expiry window without replaying everything scheduled inside it. Installation has to happen before the application loads, because code that captures a timer reference at module scope keeps the real one otherwise.

Uses for clock control

06Measure resources

Readings get taken at intervals through the run, not only at the end. The sequence of readings is the evidence. A first and last pair leaves you unable to tell a leak from a single step up.

DOM node count, registered event listener count, and JavaScript heap size cover most applications, plus whatever application specific counters you have. The signals below go through the full set, how precise each one is, and how to read it.

07Establish a baseline

The baseline gets measured after the application has warmed up, but before serious repetition begins. Every later reading is relative to that point.

The first few iterations of any journey pull in lazily loaded chunks, fill caches, compile hot functions, and allocate structures the application reuses for the rest of the session. All of that's real, and all of it's fine. Taking the baseline before it happens leaves a large jump between the baseline and everything after it, which looks exactly like a leak without being one.

A handful of warmup iterations, with five as a reasonable default, is usually enough to get past first run effects without hiding a real per iteration leak, because a real leak keeps growing long after the warmup ends.

08Analyze the trajectory

The shape of the whole run is what tells you something. One odd measurement on its own means very little, because browser memory moves around and any individual reading can land either side of a collection.

Fitting a line across the samples gives you two useful things: the slope, which is how much each iteration adds, and a measure of how well the samples actually fit that line. Growth of 8,000 nodes sitting on a straight line with a near perfect fit is a leak, and you know what one iteration adds. The same 8,000 nodes arriving in one jump at iteration 30 and staying flat afterwards is something else, probably a lazily loaded view, and worth understanding rather than failing on.

09Distinguish legitimate growth from leaks

Not all growth is a bug, and a methodology that treats it as one gets switched off in a week. Applications grow for several good reasons:

• Caches. Query caches, image caches, and memoized results are supposed to consume memory. A bounded cache grows until it's full and then stops.
• Lazy loading. Route chunks, fonts, and deferred modules arrive the first time a code path is reached, adding a permanent step.
• Browser behavior. Engines keep their own internal caches and structures, and collection is scheduled at the engine's convenience rather than yours.
• One time initialization. Long lived singletons, service workers, and connection pools allocate once and then stay put.
• Real accumulated state. If the journey adds a row to a list and never removes it, memory should grow. That's the application working.

A leak is different because it keeps pace with repetition. Legitimate growth depends on which code paths have run at least once. A leak depends on how many times they've run. When growth tracks the iteration count and shows no sign of a ceiling, that's a leak signature.

Two things sharpen this. Doubling the iteration count leaves legitimate growth roughly where it was and roughly doubles a leak. Running the same soak against a build with the suspect behavior removed confirms the leak and locates it at the same time, if the slope flattens.

10Define a soak budget

A test needs a threshold to fail against. A soak budget is the maximum resource growth you're willing to accept over a defined number of iterations.

Saying it that way keeps the two halves together. “200 MB of heap” means nothing on its own. “No more than 5% heap growth across 500 iterations of opening and closing the report drawer” is a claim a test can check and a reviewer can argue with.

Budgets differ per signal. A leaked listener is nearly always a bug, so zero growth is a defensible budget there. DOM nodes need some tolerance, because engines keep a node or two around elements a flow removes, and a CSS pseudo element with generated content counts toward the total. Heap needs the most tolerance of all, and often works better recorded than checked, until you know what your application's noise floor looks like.

The model, end to end

Put together, the methodology is a loop with an analysis stage attached, and the whole thing runs inside a session that never restarts.

Core terminology

Five terms cover most of what you need to describe a soak test precisely.

Soak loop

A repeated user journey or application lifecycle executed against the same application session.

Resource baseline

The resource measurements established before significant repetition, usually taken after a short warmup.

Resource slope

How fast a resource grows as iterations increase, measured per iteration rather than in total.

Leak signature

Resource growth that keeps pace with repeated application behavior, rather than a one off jump or a curve that levels off.

Soak budget

The maximum acceptable resource growth over a defined number of iterations, expressed as a threshold a test can fail against.

Running soak tests in CI

Endurance testing is rare on the frontend because the traditional form of it doesn't fit anywhere. A test that needs eight hours can't run on a pull request, and a check that can't run near the change finds the bug months later, in production, with nothing obvious to blame.

Time compression changes what fits. A few hundred iterations of a journey, with the clock moved on to cover the application's timers, finishes in the time an ordinary end to end suite takes. That's short enough to be a real feedback loop.

Different applications want different tiers. These numbers are examples rather than standards:

One memory reading proves nothing

One heap reading at the end of a run gives you a number that could mean almost anything. Say it reads 280 MB. That fits a serious leak, and it fits a healthy application that loaded a large dataset, filled three caches, and happens not to have been collected recently.

Several things move that number around, and none of them are bugs:

• Garbage collection timing. The engine collects when it decides to, not when you measure. Two readings taken seconds apart, with identical application state, can differ by tens of megabytes purely because one landed before a collection and the other after it.
• Caching. Query caches, image decoding caches, and memoized computations are all supposed to use memory. A cache filling to its bound looks like growth right up until it stops.
• Lazy loading. The first visit to a route pulls in its chunk. The heap steps up once and stays there, permanently and correctly.
• Application state. If the user has genuinely opened twelve documents, twelve documents' worth of memory is the right answer.
• Engine internals. Compiled code, inline caches, and the engine's own structures all count toward what you're measuring, and they grow as more of the application runs at least once.

So you measure repeatedly, across many iterations of the same behavior, and look at how the count relates to the iteration number. And you measure things more specific than bytes, because a listener count is unambiguous in a way that a heap size never is.

The signals at a glance

JavaScript heap and memory

Heap size is the broadest signal: it catches leaks that never touch the DOM, which no node count can see. A poller that pushes every response into an array leaks steadily while the DOM stays perfectly flat.

Several ways to read it exist, and they differ in what they include:

• The DevTools Protocol exposes JSHeapUsedSize through its performance metrics. This is what browser automation tools generally use. Chromium only.
• performance.measureUserAgentSpecificMemory() gives a more complete picture, including memory outside the JavaScript heap, but requires the page to be cross origin isolated, which many applications are not.
• performance.memory is the old non standard Chromium property. It's quantized for privacy reasons, and coarse enough to hide small leaks.

Whichever you use, a collection forced immediately before the reading matters, and more than one pass helps. One forced collection often leaves objects that a second pass clears, particularly in framework applications where teardown is deferred. In Chromium this needs the browser launched with --js-flags=--expose-gc. Without it you're measuring the collector's schedule as much as the application's behavior.

DOM node count

The number of nodes the renderer is keeping, whether or not they're currently in the document. In practice I find this the most useful signal of the lot, because the most common frontend leak, a listener or closure keeping a removed subtree alive, shows up here immediately and precisely.

This is different from counting elements in the document. A query like document.querySelectorAll('*').length counts what is attached, which is exactly the set of nodes that isn't the problem. Detached nodes that are still referenced never appear in it. The DevTools Protocol's Nodes metric counts what the renderer is keeping, which is the number you want.

Two quirks matter before you set a threshold:

• Clicking an element that the flow then removes can leave a small, constant number of retained nodes per iteration in Chromium, on subtrees the application is already holding.
• A ::before or ::after with generated content contributes a pseudo element and its text node to the count, so a component can read a couple of nodes higher than the markup you wrote.

Neither one grows with the iteration count, so the methodology still works. Both are reasons to allow a small non zero tolerance instead of demanding exactly zero growth.

Detached DOM trees

A detached tree is a node that's been removed from the document but is still reachable from JavaScript, so the engine can't collect it. It's the physical form most frontend memory leaks take, and it's where you look once a run has told you something is wrong.

This one is for investigation rather than for checking automatically. Finding detached trees means taking a heap snapshot in DevTools, filtering the class list for Detached, and following the retainer chain of a node back to whatever keeps it alive, which is nearly always a listener, a closure, a module level array, or a framework subscription that was never torn down.

In an automated run, the node count is your proxy: a rising count of retained nodes across iterations is the same thing, counted rather than named.

Event listeners

The count of listeners currently registered in the page. This is the cleanest of the signals, because a well designed journey that ends where it started registers and removes exactly the same listeners every time. A number that goes up by one per iteration is unambiguous, and needs no tolerance.

It also tells you the most. A leaked listener keeps the whole scope its callback closed over alive, which is usually how the detached subtree got retained too. Fixing the listener normally brings the node count down with it.

Chromium exposes JSEventListeners through the DevTools Protocol. (getEventListeners() exists too, but only inside the DevTools console, not in page scripts.)

Instrumented counters

Timers, sockets, observers, workers, and subscriptions have no built in counter, and they leak the same way: something created on setup that is never released on teardown. They also get counted the same way. The constructor gets wrapped before the application loads, incremented on creation, decremented on the call that releases it, and the difference is the count.

// Runs in the page before any application code, on every navigation.
await page.addInitScript(() => {
  const live = new Set<number>();

  const realSetInterval = window.setInterval;
  const realClearInterval = window.clearInterval;

  window.setInterval = ((...args: Parameters<typeof setInterval>) => {
    const id = realSetInterval(...args);
    live.add(id as unknown as number);
    return id;
  }) as typeof setInterval;

  window.clearInterval = ((id?: number) => {
    if (id !== undefined) live.delete(id);
    return realClearInterval(id);
  }) as typeof clearInterval;

  (window as any).__liveIntervals = () => live.size;
});

Reading it back with page.evaluate(() => window.__liveIntervals()) on each sampled iteration gives you the count. The same shape covers the rest.

Network resources

Two different things are worth watching here. The first is requests in flight or repeated: an application that adds another poller on every route change will make two requests per interval, then four, then eight. Counting requests per iteration exposes that immediately, and browser automation tools give you a request event to hook.

The second is the resource timing buffer itself. Every fetch adds a PerformanceResourceTiming entry, and the buffer keeps a few hundred entries by default before it stops accepting more. An application that clears and re-reads it, or that raises the limit, can build up entries of its own accord, which is a real if small source of growth that has nothing to do with your components.

Application caches

Data layer caches are a common source of growth that's real without being a bug. The thing to check is whether the cache has a bound.

A cache with a maximum size or a time to live fills up and then stays there, which shows as a curve that levels off. A cache keyed by something unbounded (a query cache keyed by filter combination, a memo keyed by object identity) grows for as long as the user keeps using the application. That's a leak, even though every entry in it is legitimate.

If the cache exposes its size, counting entries directly gives you much clearer evidence than the heap growth it causes.

Application specific counters

The best signal is nearly always the one you define yourself, because it names the thing that's leaking instead of describing its side effects.

Editors can count live document instances. Charting layers can count chart objects that were never disposed. A map component can count layers, a virtualizer can count rendered row instances, a video player can count media elements. A counter behind a flag adds nothing to production, and you can check it directly.

// In the application, behind a build flag or test hook.
if (import.meta.env.DEV || window.__SOAK__) {
  window.__counters = {
    charts: () => chartRegistry.size,
    editors: () => editorRegistry.size,
    subscriptions: () => store.listenerCount(),
  };
}

The standard for calling it a leak

Whichever signals you collect, the standard stays the same. One reading tells you nothing on its own, and two readings only tell you they differ. Evidence is a sequence of readings that rises in step with how many times a specific behavior has run.

The strongest case has three parts: growth that tracks the iteration count, a slope that stays roughly steady rather than flattening off, and a matching drop in that slope once you remove the suspected cause. Anything less is a lead worth following rather than a bug worth failing a build over.