Skip to content
Latchkey

How to Speed Up Playwright in CI

Playwright already parallelizes within a machine, but CI wins come from sharding across machines, caching browsers, and not recording everything.

Playwright runs workers in parallel on one host. To go faster in CI you shard the suite across runners, cache the browser binaries, and stop capturing traces and video for passing tests.

1. Shard across runners

Playwright has native sharding. Split the suite across machines and merge reports after.

.github/workflows/ci.yml
strategy:
  matrix:
    shard: [1/4, 2/4, 3/4, 4/4]
steps:
  - run: npx playwright test --shard=${{ matrix.shard }}

2. Cache the browsers

Cache ~/.cache/ms-playwright keyed on the Playwright version so cold runners skip the browser download.

.github/workflows/ci.yml
- uses: actions/cache@v4
  with:
    path: ~/.cache/ms-playwright
    key: playwright-${{ hashFiles('package-lock.json') }}
- run: npx playwright install --with-deps

3. Capture traces and video only on failure

Set trace: "on-first-retry" and video: "retain-on-failure" in the config. Recording every passing test inflates run time and artifact size for no diagnostic value.

4. Match worker count to runner CPUs

Playwright defaults workers to host CPU count. A right-sized Latchkey runner with predictable CPU lets you set workers deterministically instead of fighting noisy-neighbor throttling on a shared hosted runner.

Key takeaways

  • Use native --shard to spread the suite across machines.
  • Cache ms-playwright so browser installs do not repeat on cold runners.
  • Record traces and video only on retry/failure to cut time and artifact size.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →