Playwright in Pictures is a series of articles where I use playwright-timeline-reporter to visualize different Playwright concepts with simple timeline charts. Here's the first article in the series.
Playwright’s fullyParallel mode is often treated as a simple performance switch. In practice, it changes how the runner schedules work, which leads to different execution shapes for the same test suite.
In this post I’ll show a visual comparison of different modes and highlight when fully parallel is slower.
Example Setup
I use a minimal suite:
-
spec1.test.ts→ 1 test -
spec2.test.ts→ 5 tests workers = 2
This setup is enough to expose how scheduling works.
Non-Fully Parallel
By default, Playwright assigns entire files to workers. Once a worker picks a file, it runs all tests in that file in order.
Running the example suite:
npx playwright test --workers 2
produces the following timeline:
In this setup, Worker 1 runs the single test from spec1, while Worker 2 executes all 5 tests from spec2.
Tests inside a file cannot move to another worker. Even if one worker is idle, it cannot pick up remaining tests from other running files.
In practice, the total run time is defined by the longest file, not by the total amount of work.
Fully Parallel
With --fully-parallel enabled, Playwright schedules individual tests instead of files. File boundaries stop mattering. Workers take the next available test.
Running the example suite with --fully-parallel:
npx playwright test --workers 2 --fully-parallel
The timeline:
With the same setup, the 5 tests from spec2 are split across both workers, keeping the timeline balanced.
The total run time drops from 5.6s to 3.5s.
This shifts the execution model. It now follows individual tests instead of the longest file.
Is Fully Parallel Always Faster? No.
Fully parallel mode may be slower if tests rely on heavy worker hooks or worker fixtures.
To illustrate this, I added a heavy beforeAll hook to spec2:
test.beforeAll(async () => {
await expensiveSetup()
});
Running the tests without fully parallel:
The beforeAll setup cost (yellow bar) is paid once in Worker 2 and reused across all tests in that file.
Now run the same suite with --fully-parallel:
Here, beforeAll runs twice, once per worker. As the number of workers grows, the setup is repeated more times.
Total run time increases from 15s to 20s after enabling fully parallel mode.
When setup dominates test time, --fully-parallel makes the run slower.
Key Takeaways
- By default, Playwright runs tests per file: files are split across workers, tests inside a file run sequentially.
- With fully parallel mode, tests are split across workers and run independently.
- Fully parallel mode can slow tests down. Check your test distribution and setup before enabling it.
Thanks for reading ❤️
👉 Next in the series: Playwright in Pictures: Why Workers Restart?
Top comments (3)
The beforeAll cost multiplying per worker is a gotcha that catches people off guard - especially on CI where you might throw more workers at a slow suite expecting a linear speedup and get the opposite.
The mental model shift is the useful takeaway here: fully parallel optimizes for test count distribution, not setup cost amortization. Once you frame it that way the tradeoff becomes obvious before you even run it.
Timeline charts make this click instantly — the 'what is my test runner actually doing' question is usually answered with hand-wavy words. One gotcha worth flagging for anyone flipping fullyParallel on: if your tests share any global state (DB seeds, auth tokens, feature flags) they'll start flaking in ways that look random but are actually deterministic race conditions. Fix it by scoping every fixture per-worker with the worker fixture, not by disabling parallelism. Looking forward to the rest of this series.
Thank you!