If you've been using Playwright for a while on a large test suite, you've probably used the --shard option to parallelize your tests across multiple machines or CI runners. At first, it seems like the perfect solution. But as your test suite grows, you start to notice a frustrating problem: some of your test runners finish in a reasonable amount of time, while others can take significantly longer. Ultimately, you're stuck waiting for the slowest one to complete.
The main reason for this is how Playwright's sharding works: it's static. It splits the test files into even chunks before the tests start and assigns each chunk to a specific machine or CI runner. For example, if you're sharding across 4 runners, it divides your tests into 4 predetermined groups.
# Runner 1 runs the first quarter of tests
npx playwright test --shard=1/4
# Runner 2 runs the second quarter
npx playwright test --shard=2/4
# ...and so on
This approach works perfectly if all your tests take exactly the same amount of time. But in the real world, that never happens. Some tests are short and simple, while others involve complex user flows and take much longer. This static division leads to a significant imbalance:
Uneven Load Distribution: One runner might get all the "easy" tests and finish early, sitting idle.
Wasted Resources: While one runner is idle, another is struggling with a long queue of "hard" tests.
Longer Execution Times: Your total test run time is dictated by your slowest shard, not the average.
A Real-World Example
To make this problem more concrete, let's look at a screenshot from a real GitLab CI pipeline where a suite of 53 tests was distributed across 4 runners.
The entire test suite finished in 6 minutes and 3 seconds.
Run 2: The Imbalance of Static Sharding
Next, I split the tests across two runners (simulating two CI machines), each running 2 parallel workers.
The logs clearly show the magic of dynamic distribution. Instead of being locked into a predefined group of tests, workers pull from a single, shared queue. When a worker finishes a test (whether short or long) it immediately requests the very next test from the central queue. This ensures that even if one worker is tied up with a long test, another can complete several shorter tests in the meantime, effectively balancing the load in real-time.
The entire test suite finished in 6 minutes and 5 seconds, nearly matching the ideal baseline and eliminating the massive imbalance caused by static sharding.
| Method | Total Execution Time |
|---|---|
| Baseline (No Sharding) | 6m 3s |
| Playwright Sharding | 8m 36s |
| Pawdist | 6m 5s |
The benchmark speaks for itself. Pawdist provides the scalability of distributed testing without the performance penalties of static sharding.
Ready to Speed Up Your Tests?
If you're looking to optimize your Playwright test execution times and make the most of your CI resources, give Pawdist a try!
By switching to a dynamic distribution model, you can achieve:
Faster Overall Execution: Your suite finishes when the last test completes, not the slowest shard.
Optimal Resource Utilization: No more idle CI runners waiting for others to catch up.
True Dynamic Load Balancing: Tests are assigned on-demand for maximum efficiency.
For detailed installation and usage instructions, you can check out the project's comprehensive README on GitHub.
SOCIAL SHARE CARD GENERATOR