BrowserContext resource reclamation in high-volume test cycles

Short answer: await context.close() releases everything Playwright owns for that context — pages, network handlers, storage state, cookies, and the corresponding browser-side incognito profile — but it does not guarantee the Chromium process's resident set size (RSS) returns to its exact pre-context baseline. And no, Playwright documents no fixed cycle-count threshold after which you must restart the browser.

What close() actually reclaims

Calling browserContext.close() is the reliable reclamation point. It tears down the context's pages, event listeners, routing, and storage, and tells Chromium to destroy the underlying profile. If you explicitly close pages first, that is fine but redundant — closing the context closes its pages. The key requirement is that every context is closed, ideally in a finally or afterEach hook so failures don't skip cleanup:

test.afterEach(async ({ context }) => {
  await context.close();
});

Keep one Browser for the whole suite and close it in afterAll. Restarting the browser per test is the expensive path contexts exist to avoid.

Why RSS may still drift upward

This is the likely explanation rather than a confirmed leak: even with perfect cleanup, the browser process's RSS typically does not return to its exact starting value. V8 and Blink allocators retain freed arenas for reuse, caches (font, shader, code) grow, and memory fragmentation accumulates. So a gradual, sub-linear increase over hundreds of cycles is expected behavior, not necessarily a leak. A true leak shows unbounded growth proportional to cycle count; allocator retention plateaus.

Common real leak sources in high-volume suites are not the context itself but what hangs off it: unresolved promises, downloads never awaited, tracing or video artifacts retained after failures, and contexts left open when a test throws before cleanup. Parallel workers should each close only the contexts they created, and concurrency should be bounded so simultaneous contexts stay within file-descriptor and memory limits.

No documented restart threshold

There is no documented number of context cycles after which a browser restart is required. The practical approach is to measure and set your own policy. A simple verification loop:

const browser = await chromium.launch();
const baseline = process.memoryUsage().rss;
for (let i = 0; i < 500; i++) {
  const ctx = await browser.newContext();
  const page = await ctx.newPage();
  await page.goto('about:blank');
  await ctx.close();
}
global.gc?.(); // node --expose-gc
console.log(process.memoryUsage().rss - baseline);
await browser.close();

Also watch the Chromium child processes' RSS via your OS tools — Node-side memory can look stable while the browser retains resources. If growth is unbounded across batches, restart the browser on a schedule (e.g., every N thousand contexts) as a pragmatic bound; if it plateaus, no restart is needed.

Caveats

Exact cleanup timing and defaults are version-sensitive; confirm against the Playwright release your project pins. Closing a context while an async step still uses it causes flaky errors, so gate cleanup on test completion. If you reuse contexts instead of creating fresh ones, explicitly reset cookies, storage, and permissions — otherwise state leaks between tests even when memory does not.