[Bug]: Playwright 1.57 - No way to use open-source Chromium, Chrome for Testing causes high memory usage (20GB+ per instance)

[andresalbertomoralesmitre]

Version

1.57.0

Steps to reproduce

After upgrading to Playwright 1.57, the browser now launches Chrome for Testing instead of the lightweight open-source Chromium used in earlier versions. This change dramatically increases memory usage and causes tests to crash under normal parallel execution.

**> What’s happening

Playwright always launches Chrome for Testing, even when the config explicitly requests Chromium.

The bundled browser located at ~/Library/Caches/ms-playwright/chromium-1200/chrome-mac-arm64/ is actually Google Chrome for Testing.app, not Chromium.

A single Chrome for Testing instance uses far more RAM than the previous Chromium builds.

With just 3 workers, each Chrome instance grows to ~20GB, pushing system load over 27 and triggering serious memory pressure.

Attempts to force Chromium (all unsuccessful)

browserName: 'chromium'

Removing device presets (e.g. devices['Desktop Chrome'])

Setting channel: undefined

Not specifying any channel at all

All of these still launch Chrome for Testing.

Workaround

Running tests with:

--project=firefox**

works normally and keeps memory usage stable. Firefox does not exhibit this high-memory behavior.

Request / Question

Is there any supported way in Playwright 1.57+ to use the actual open-source Chromium binary instead of Chrome for Testing?

Expected behavior

browserName: 'chromium' should launch open-source Chromium with reasonable memory usage.

Actual behavior

Chrome for Testing launches instead. Each instance uses ~20GB memory, causing system crashes with multiple workers.

Additional context

Config

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  use: {
    browserName: 'chromium',
    launchOptions: {
      args: [
        '--disable-dev-shm-usage',
        '--disable-gpu',
        '--disable-extensions',
        '--disable-background-networking',
        '--disable-sync',
        '--disable-translate',
        '--no-first-run',
        '--disable-features=TranslateUI',
        '--js-flags=--max-old-space-size=512',
      ],
    },
  },

  // On CI → single worker, locally → 3 workers
  workers: process.env.CI ? 1 : 3,

  projects: [
    {
      name: 'chromium',
      use: { browserName: 'chromium' },
    },
  ],
});

Environment

System:
  OS: macOS 26.1
  CPU: (10) arm64 Apple M1 Pro
  Memory:  16.00 GB
Binaries:
  Node: 20.19.3
  Yarn: 1.22.22
  npm: 11.6.4
IDEs:
  VSCode: 2.1.50
Languages:
  Bash: 3.2.57
npmPackages:
  @playwright/test: 1.57.0 => 1.57.0 
  playwright: 1.57.0 => 1.57.0

[Skn0tt]

Hi Andres. Starting with v1.57, Playwright no longer provides a Chromium build, and fully uses Chrome for Testing instead. This is the first report we hear about high memory usage, and there's a chance this is a bug in Chrome. I see you're passing custom launch args, which we don't provide support for (see https://playwright.dev/docs/api/class-browsertype#browser-type-launch-option-args). Does the high memory usage also occur without custom launch args? If yes, please provide us with a reproduction case that we can investigate and potentially share with the Chromium team.

[gokultw]

I have also noticed this issue. I usually run with 5 workers, and after the upgrade the tests are taking longer to complete. A test that used to finish in 3 minutes is now taking more than 10 minutes, and also tests are failing due to timeouts.

[Skn0tt]

We closely looked at our own test suite speeds, and Chrome for Testing didn't make a big difference in speed. When you look at your test reports, do you notice particular actions taking longer now, or is it just slower across the board? Ideally, if you could provide us with an example of a test that's taking longer in 1.57, we'd love to take a look. Also, maybe you could spot-check if switching to channel: "chrome" has an impact to speed for you, so we get a better picture of what's happening.

[Maaxion]

We've also experienced this issue in our CI. Running Vue 3.5 + Vite. Locally playwright runs fine, same tests on Jenkins CI ends up using up 20G+ of memory and crashes tests.

Our tests are exceedingly simple, as we bumped into this issue when we were setting up our CI:

  await page.goto('');

  await expect(page).toHaveTitle('Insert title');
  await expect(page.getByRole('heading', { name: 'insert heading' })).toBeVisible();

and

  await page.goto('');

  await page.getByRole('menuitem', { name: 'name here' }).click();
  await expect(page.getByRole('heading', { name: /some string/ })).toBeVisible();

[Skn0tt]

Thanks for the report. Sounds like a memory leak in Chrome for Testing. Could you provide us with a reproduction example that crashes on your Jenkins CI, and information about what operating system your CI is running?

[Maaxion]

I have limited access to the Jenkins server, I know it runs debian bookworm but precise version I do not know. Suspect its latest.

In our case running with --project=firefox does not prevent the OOM crash.

Tests are run using playwright test --project=firefox

Running playwright 1.57.0

Issue is not reproducible on local dev machines. I can see after the holidays if I can spin up a separate debian bookworm machine to try to replicate this and get more information.

[Skn0tt]

If Firefox is also experiencing an OOM crash, then maybe it's not related to Chrome for Testing but something else. Were you also seeing these crashes on Playwright 1.56?

[resithuseyin]

Hi Simon, We are seeing the same problem after upgrading from Playwright v1.44.0 to v1.57.0. Tests started failing randomly in our CI environment (Jenkins), sometimes even during the initial page.goto() step.   When running only a small set of tests locally, the issue may not be noticeable and seems to surface only when running a larger test suite. Downgrading to Playwright v1.56.1 has resolved the issue for us so far.

[MiladSadinam]

With the same setup (Playwright 1.57, Chrome for Testing, Windows 11), I experience that the Chrome Developer Console is painfully slow. E.g. when debugging and I try to pick a HTML element.

[devopsbob]

I have a set of accessibility tests which have become painfully slow. I have not looked prior for this behavior, but now my tests run many, many chrome-headless-shell with many varying command line parameters that make me wonder about background process usage using ms-playwright!

.cache/ms-playwright/chromium_headless_shell-1200/chrome-headless-shell-linux64/chrome-headless-shell

This is in wsl/deb13 environment.

[andresalbertomoralesmitre]

Adding another data point.

We’re seeing the same behavior outside of our main test suite as well. Even Storybook, which internally uses Playwright, starts crashing locally after upgrading to Playwright 1.57.

In our case:

• Upgrading Playwright (directly or transitively via Storybook) to 1.57 caused tests to crash even when running locally

• CPU and memory usage spiked aggressively, to the point where the system became unusable and required a laptop restart

• Because of this, we were unable to meaningfully collect debugging data once the issue started reproducing

Workaround

Downgrading all usages of Playwright to 1.56.1 (direct dependencies and any libraries pulling it in, including Storybook) immediately stabilized:

Local test runs

CI execution

CPU and memory usage

After the downgrade, the crashes and extreme resource usage stopped completely.

At the moment, sticking to 1.56.1 everywhere Playwright is used is the only reliable mitigation we’ve found.

[mivanov1989]

Thumbs up for the resolution of the issue. In our case, we run about 3000 long e2e tests with 4 workers. With v1.56.1, the heap memory usually grows up to 6 GB. With v1.57.0, it exceeds the size of 8 GB at 80% of the test run completeness.

[pavelfeldman]

• Could you all give us an idea on your content? It could be that the GPU or media stack or some other aspect of migration to Chrome for Testing triggered a bigger footprint. Our internal testing on generic loads did not yield significant differences.
• Where are you running these? Locally? Clouds?
• Please also tell us if you are running it within an enterprise with Chrome enterprise poliсies in effect.

[devopsbob]

My content is quite basic utilizing a jekyll static site. It is calling axe.core analyze during the testings. It includes testing for rouge-highliter code block accessibilty and WCAG2.2 content checks. My content is here: https://www.mijug.net/docs

I am running these tests locally, on a Windows 11 machine, executing in a WSL2 hosting debian 13.

Lenova laptop on home network. No Chrome enterprise policies in effect.

Since my post I have made many improvements to try to bring down the effect. I pinned to 1.56.1. I refactored out all of the injectApi to replace with context pages. (using contexts instead of pages had a big impact) I also tuned my launchArgs into various chrome project profiles to do something you were suggesting. Here is the full launchArgs for the accessibility testing: // Memory-optimized browser launch options (Chrome for Testing mitigation) launchOptions: { args: [ // Memory optimization flags for Chrome for Testing "--disable-dev-shm-usage", // Reduce /dev/shm usage "--disable-gpu", // Disable GPU acceleration in headless "--disable-background-networking", // Reduce background network activity "--disable-backgrounding-occluded-windows", // Reduce background processing "--disable-renderer-backgrounding", // Keep renderer active "--disable-features=TranslateUI,VizDisplayCompositor", // Disable non-essential features "--no-sandbox", // Reduce security overhead in CI "--disable-web-security", // Reduce security checks "--disable-extensions", // Disable extensions "--disable-plugins", // Disable plugins "--disable-default-apps", // Disable default apps "--no-first-run", // Skip first-run experience "--disable-sync", // Disable sync features "--disable-translate", // Disable translation "--memory-pressure-off", // Disable memory pressure detection "--max_old_space_size=2048", // Limit V8 heap size "--js-flags=--max-old-space-size=2048", // Additional V8 memory limit ],

I'm trying to refactor out any deprecated patterns and legacy usages. My intent to then switch it back to 1.57 and use a few measure utilities to see what impact I get.

The best tell on my processing came from using the DEBUG environment variable for Playwright. Maybe this will help others see the impacts: DEBUG=pw:api npx playwright test tests/e2e/accessibility-consolidated.spec.ts --project=chromium-light