skip to content

What do you gain and give up by replacing a browser grid with Playwright's worker parallelism?

level: middleimportance: should knowfreq 54%

answer

  1. Concurrency moves inside the run
  2. Processes on one machine, not nodes
  3. Default tied to core count
  4. A second axis splits the suite
  5. Parallelism exposes hidden test coupling

basics

~20 s

You gain a fleet you no longer operate: Playwright 1.63 runs worker processes on the run machine, defaulting to half its logical cores. You give up operating-system spread, and one machine's cores become the ceiling.

solid answer

~40 s

A grid spreads tests across machines you operate; the Playwright runner spreads them across **worker processes** on the machine running the suite, each owning a browser and creating a fresh context per test. In 1.63 workers default to half the logical CPU cores, tunable with `--workers` and `fullyParallel`, and `--shard=1/3` splits a run across independent CI jobs. The gain is real: no hub, no node images, no queue, and scaling is a config change. The costs are equally real -- concurrency is capped by one machine's cores and memory, order-dependent tests that survived a serialised queue break immediately, every runner needs browsers installed, and a grid's Windows/macOS/Linux spread has to be rebuilt as several runner images. It is a trade, not an upgrade.

code

bash · 4 lines
bash
npx playwright test --workers=4
npx playwright test --shard=1/3
npx playwright test --shard=2/3
npx playwright test --shard=3/3

go deeper

for a junior

Know that the runner executes tests in several worker processes at once by default, and that this is why tests must not depend on each other or share the same fixed data.

for a middle

Explain the model: workers are processes on the run machine, the default follows core count, and sharding splits the suite across CI jobs. Name the ceiling that a single machine imposes.

for a senior

Demonstrate measurement: find whether wall-clock is spent queueing or executing, chart the worker curve until it flattens, and budget the repair of order-dependent tests as part of the move.

for a principal

Own the infrastructure trade: leaving a shared fleet shifts its cost onto the teams that stay, and rebuilding operating-system spread as runner images is a pipeline you now maintain.

## The swap you are actually making A grid puts browsers on machines you operate and hands tests out to them over the network. The Playwright test runner puts the concurrency inside the run: it starts several **worker processes** on the machine executing the run, and each worker owns its own browser instance and creates fresh browser contexts per test. In Playwright 1.63 the default is half the machine's logical CPU cores, overridable with `--workers` or `workers` in `playwright.config.ts`, and `fullyParallel: true` lets files run their tests in parallel rather than only running files side by side. `--shard=1/3` splits the whole suite across independent CI jobs, so a second axis of scale comes from adding runners rather than adding grid nodes. ## What you gain - **No fleet to operate.** No hub, no node registry, no drifting browser images, no queue when two teams release on the same afternoon. - **Cheap isolation.** Fresh contexts inside one browser process cost far less than a fresh session per test, so a higher worker count is affordable on modest hardware. - **Scale by job, not by node.** Sharding turns "we need more capacity" into a CI configuration change rather than a procurement conversation. - **Failure evidence travels with the run.** Traces and videos are produced by the same run that failed, not fetched from whichever node happened to serve the test. ## What you give up - **A hard ceiling per job.** One machine's cores and memory bound how many workers help; past that point more workers make things slower, and browsers are memory-hungry. - **A test-independence tax.** Order-dependent tests that survived a serialised grid queue fail immediately under parallel workers, and that repair lands on the migration, not on the tool. - **Operating-system spread.** A grid can hold Windows, macOS and Linux nodes. Matching that means running the suite on several CI runner images, which is a pipeline design problem you now own. - **Setup on every runner.** Each runner needs the browsers installed and cached; a cold runner pays a download before the first test starts. ## Grid node versus local worker | Concern | Owned grid | Playwright workers | |---|---|---| | Unit of concurrency | a node or session slot | a worker process on the run machine | | Scaling step | add or rent a node | raise `--workers`, then add shards | | Per-test isolation cost | a fresh remote session | a fresh browser context | | Ceiling | fleet size and licence limits | one machine's cores, then job count | | Who operates it | an infrastructure owner | whoever owns the CI config | ## Sizing it honestly before you commit 1. Measure the current suite's wall-clock time and its real bottleneck -- queueing for a node, or the tests themselves. 2. Run the ported slice at one worker, then at half the cores, then at the cores, and record where the curve flattens and where flakiness appears. 3. Divide the remaining time by the number of shards you can afford in CI, and compare that to the grid number you started with. For a legacy insurance-quote suite, the honest answer is often "faster and cheaper, but only after the order-dependent tests are fixed" -- and that repair is the real line item. ## When staying on the grid still wins - The suite genuinely needs operating systems or engines the bundled set does not offer. - The grid is already funded and idle, and the bottleneck is test design rather than capacity. - Other teams depend on the same fleet, so leaving does not remove its cost, it just moves the whole bill onto whoever stays.

  • Why does raising the worker count past a point make a suite slower rather than faster?
    Every worker holds a browser process, and browsers are memory- and CPU-hungry. Past the machine's real capacity, workers contend for cores and RAM, actions slow down, and tests that were tuned near their timeouts start failing. The curve flattens and then reverses, which is why the number is measured rather than guessed.
  • The suite passed on the grid but fails under parallel workers. What is usually wrong?
    Almost always hidden coupling: shared accounts, shared quote records, fixed database rows, or tests that assume the order the grid happened to serialise them into. The parallel run did not create the defect, it revealed it, and the repair belongs to the migration estimate rather than to the tool.
  • If sharding scales the suite anyway, why tune workers at all?
    Shards cost CI jobs, and each job pays its own startup and browser-install time. Getting worker count right first means each shard uses the machine you already pay for, so you buy fewer jobs to hit the same wall-clock target. Tune within the job, then split across jobs.

saying these in an interview costs you the question

  • Claiming parallel workers make any suite faster automatically
  • Assuming more workers always means less wall-clock time
  • Forgetting that each runner must install browsers first
  • Believing local workers reproduce a grid's operating-system spread
  • Treating flakiness under parallelism as a tool defect