Most browser automation tools run outside the browser — connecting via CDP over a WebSocket, issuing commands, and waiting for responses. What if Playwright ran inside the browser instead?
We benchmarked three ways to run the same Playwright commands and the results were dramatic.
The Setup
We ran the same commands on TodoMVC across three modes:
-
playwright-cli— Playwright's official CLI. Each command is a separate process. -
playwright-replstandalone — Our CLI in default mode. A persistent REPL — start once, run many commands. -
playwright-replbridge — Our CLI connected to the Dramaturg Chrome extension. Playwright runs inside Chrome via playwright-crx.
The Results
| Command | playwright-cli |
Standalone | Bridge |
|---|---|---|---|
snapshot |
211ms | 4ms | 14ms |
click |
1,538ms | 1,046ms | 30ms |
hover |
1,240ms | 1,050ms | 28ms |
fill |
1,236ms | 1,036ms | 7ms |
press |
1,216ms | 1,033ms | 11ms |
eval |
1,220ms | 1,010ms | 3ms |
screenshot |
274ms | 107ms | 129ms |
tab-list |
217ms | 4ms | 4ms |
cookie-list |
201ms | 3ms | 2ms |
What's Going On?
playwright-cli: ~200ms baseline + action overhead
Every playwright-cli command spawns a new Node.js process, connects to the running browser session, executes the command, and exits. That's ~200ms before anything happens. Actions like click and fill add another ~1,000ms of Playwright auto-waiting on top.
Standalone: fast queries, slow actions
playwright-repl starts once and keeps the connection open — no per-command startup cost. Queries like snapshot and tab-list are instant (3-4ms). But actions still take ~1,000ms because they go through the same external CDP pipeline: Node.js → WebSocket → Chrome → execute → wait for navigation/network idle → return.
Bridge: fast everything
This is where it gets interesting. In bridge mode, playwright-repl connects to the Dramaturg Chrome extension, which runs Playwright inside Chrome's service worker via playwright-crx. There's no external CDP connection — everything happens in-process.
A click that takes 1,046ms in standalone takes 30ms in bridge mode. That's 35x faster.
Why? A typical click involves many CDP round-trips under the hood:
- Wait for element to be visible (poll via CDP)
- Wait for element to be enabled (poll via CDP)
- Scroll element into view (CDP)
- Calculate click coordinates (CDP)
- Perform the click (CDP)
- Wait for potential navigation (CDP events)
Each step adds latency when going through an external WebSocket. In bridge mode, each internal call is microseconds — so even a dozen steps stay under 30ms.
Why Queries Are Fast Everywhere
snapshot is 4ms in standalone and 14ms in bridge. Both fast. Why?
Because snapshot is a single CDP call — walk the accessibility tree, return the result. One round-trip is fast regardless of whether it's external or in-process. The difference only shows up when commands involve many CDP round-trips, which is what actions do.
The Real-World Impact
For interactive use, the difference is feel:
-
playwright-cli: type a command, wait 1-2 seconds, see result → feels sluggish - Standalone REPL: queries are instant, actions take ~1 second → usable
- Bridge mode: everything feels instant → flows like a conversation with the browser
For AI agents running via MCP, the difference is throughput. An agent exploring a page might run 50-100 commands. At 1 second per action, that's 1-2 minutes of waiting. At 30ms per action, it's 3 seconds.
Try It
# Install
npm install -g playwright-repl
# Standalone mode
playwright-repl --headed
# Bridge mode (requires Dramaturg extension)
playwright-repl --bridge
Install Dramaturg from the Chrome Web Store for bridge mode.
Top comments (0)