Worker tuning has a ceiling: one machine. Past that, you split the suite across machines, which Playwright calls sharding.
npx playwright test --shard=1/4
npx playwright test --shard=2/4
npx playwright test --shard=3/4
npx playwright test --shard=4/4
Four machines, each running a quarter. Combined with workers, four machines at six workers each gives twenty-four tests running at once.
How Playwright splits. By default it distributes whole test files, aiming for a roughly even count. That is fine when files are similar in duration and badly unbalanced when they are not: one shard finishes in four minutes, another takes eleven, and your run takes eleven.
Balance by duration, not by count. Playwright can use timing data from a previous run to distribute more evenly. Without that, the practical fix is the same as in the Cypress track: split your slowest files. One twelve-minute file sets a floor no sharding can go under.
Measure first. It is almost always a small number of files causing the imbalance.
Merging reports, which is the step teams miss.
Each shard produces its own report. Four shards means four partial reports and no overall picture, which makes the whole run hard to read.
# on each shard
npx playwright test --shard=$SHARD/4 --reporter=blob
# after all shards finish
npx playwright merge-reports --reporter=html ./all-blob-reports
The blob reporter exists for exactly this. Merging gives you one HTML report with every test, every trace and every attachment, as if it had run on one machine.
In your CI configuration this means the shards upload their blob reports as artifacts, and a final job downloads all of them and merges. That final job is easy to forget and its absence is usually why a team says sharding made their reporting worse.
The cost side, which is a real senior consideration. Four machines for ten minutes costs roughly the same as one machine for forty. You are buying wall-clock time, not compute. That is usually worth it for a merge gate and rarely worth it for a nightly run nobody is waiting on.
So shard the runs people wait for. Do not shard the ones they do not.
Sharding requires independence. Shards cannot coordinate. They run simultaneously against the same application and database. Any test that depends on order, or on data another test creates, will fail unpredictably depending on which shard it lands in.
This is the same requirement as parallelism, one level up, and it is why the test data discipline from the intermediate track is load-bearing at this level rather than merely tidy.
Retries interact with sharding. A retried test re-runs on the same shard. If a shard's machine is the problem, say it is running low on memory, retries on that machine will fail too. When one shard fails disproportionately, suspect the machine before the tests.
Remember this: split slow files before adding machines, always merge blob reports, and shard only the runs people are waiting for.
Reference: Sharding.