Playwright load testing, honestly

No, and most of the guides that say otherwise are cloud runner sales pages. Playwright is a protocol driver for real Chromium, Firefox and WebKit. It launches a full browser process per session and does JavaScript execution, CSS layout, compositing, the works. That is exactly the wrong shape for load testing in the classical sense, because the resource cost per virtual user is one to two orders of magnitude higher than a protocol-level tool like k6 or Artillery HTTP. What Playwright is genuinely good at is reproducing user experience under concurrent load, which is a real and useful problem, just not the problem the phrase load testing usually names.

The phrase conflates four distinct problems. (1) Protocol volume: can my API serve 50,000 requests per minute? Wrong tool, use k6 or Artillery HTTP. (2) Frontend load: does my React bundle parse fast on a mid-tier phone? Wrong tool, use Lighthouse CI or WebPageTest. (3) UX under backend load: while the backend is being hammered by a protocol tool, do real users still see the checkout button within 3 seconds? Playwright is the right tool here, but only for the browser half, running alongside k6 or similar. (4) Concurrency bug reproduction: does racing 50 users to click 'Buy' at the same moment expose a double-charge? Playwright is also right here, and this is the case where you actually want N real browsers firing at once.

Seven lines of bash. Set ASSRT_ISOLATED=1 in the environment so every Playwright MCP process spawns with the --isolated flag. That gives each Chromium an in-memory user-data-dir instead of sharing ~/.assrt/browser-profile. Then pipe N scenario IDs into xargs -P N running npx @assrt-ai/assrt run --url ... --plan-file scenario.md --video --json. Each parallel worker writes its own JSON report and its own WebM recording. 20 to 40 workers is the practical ceiling on a 16 GB developer laptop. Past that, rent a single dedicated box rather than a fleet of cloud runners.

Both work. The env var is more convenient for xargs because xargs repeats its command template N times and inherits the parent environment, so you set the flag once and every child uses it. cli.ts:114 resolves ASSRT_ISOLATED as 1, true, or unset, and the resulting boolean is passed all the way down to launchLocal in browser.ts:258-351, which appends --isolated to the Playwright MCP args at line 308. In --isolated mode, the whole singleton-lock cleanup path at lines 319-342 is skipped (kill orphan Chromes, delete SingletonLock, delete SingletonSocket, delete SingletonCookie), because there is no shared disk profile to contend for. That cleanup path is the reason default-mode assrt processes cannot run concurrently.

Order of magnitude: each headless Chromium on a mostly-static page costs about 200 to 400 MB of resident RAM and roughly one CPU core for short bursts during navigation and rendering. On a 16 GB developer laptop with 8 performance cores, the practical ceiling is 20 to 40 workers before you start swapping or CPU-throttling. On a dedicated box with 64 GB of RAM, you can reach 100 to 150. Past that, per-worker resource contention dominates and your timing measurements become unreliable noise. This is also why cloud runners charge so much: Artillery's rule of thumb is one vCPU per virtual Playwright user, and that vCPU is the bulk of the bill.

Two things that only a real browser can observe. First, frontend timing under backend stress. k6 can tell you that a POST /api/checkout returns in 1.8 seconds at p95 under load; only Playwright can tell you that the checkout button actually becomes clickable 4.1 seconds after the page starts to load, because the render-blocking analytics bundle does not care that the API is slow. Second, race conditions that only fire through the real event loop, like double-submits from two tabs, stale CSRF tokens from a pre-fetched form, or optimistic UI that rolls back. Both of these require the full DOM, the full JavaScript VM, and real layout. Neither is captured by hitting the HTTP endpoint directly.

Single-scenario by design. Each assrt invocation spawns one @playwright/mcp process that drives one browser through one plan file of #Case blocks, and exits. There is no fleet mode, no VU ramp-up, no Artillery-style scripting. The whole point of the isolated mode + xargs pattern is that you do not need any of that. The OS is already a perfectly good fleet manager for N independent browser processes. What you get per worker is a real Playwright run with video, a JSON report, and per-step screenshots on disk. What you do not get is consolidated reporting across workers; aggregate the N JSON files yourself with jq or a tiny script if you care.

Two things. First, rate limiting: most production APIs will start returning 429 around the 30 to 50 concurrent-user mark, and your load test becomes a test of your rate limiter instead of your checkout flow. Either coordinate with whoever owns the rate limits or point at a staging environment that has them disabled. Second, session isolation: if your auth uses cookies and every worker logs in as the same user, you are testing one user clicking 50 times, not 50 users. Either fan out across N test accounts (pass emails through the scenario file as {{EMAIL}} variables and interpolate at runtime), or use create_temp_email in the scenario itself to mint a new disposable email per worker via mail.tm.

Every worker runs the same markdown file. A plan is a sequence of #Case blocks with one-line headers and bullet steps underneath. There are no selector strings, no waits, no retries; the agent loop reads a fresh accessibility-tree snapshot before every action and picks elements by ref. That matters for load tests because a selector-based .spec.ts will flake under concurrency in ways that make the results unreadable (was that a real bug or just a timing race with the selector?), while a snapshot-based agent loop fails on actual state and passes on actual state. You get the classical Playwright primitives underneath via @playwright/mcp, and the scenario file stays under 30 lines.

Three honest triggers. (1) You need more than 150 concurrent real browsers for a single test window, and cannot split the scenarios across multiple machines easily. (2) You need geographic distribution (users from eu-west hitting a us-east origin with real TCP round-trip latency), which a single laptop obviously cannot simulate. (3) You need to run this on every pull request as blocking CI, and the wall time on a single box is not acceptable. Below those thresholds, the local pattern is strictly better than a cloud runner, because you own the environment, the tests stay debuggable, and there is no vendor-specific YAML to maintain.

The CLI and MCP server are MIT licensed on npm as @assrt-ai/assrt. When you run locally, the target URL, DOM snapshots, and screenshots go to whichever LLM endpoint you configured (Anthropic by default, or any Claude-compatible base URL). Video and JSON reports stay on disk under /tmp/assrt/. Nothing is uploaded anywhere unless you explicitly opt in to cloud sync. Compare against the $500 to $7500 per month cloud runners, which route every DOM through their backend by design and keep your scenarios on their servers.