#Benchmarks

All numbers come from benchmark scripts in the repository, which you can run yourself. They come from one machine (a 4-CPU cloud container) and small demo apps. On a slow app, the app's own time dominates, so read them as the tool's overhead, not as a promise about your suite.

#Test runner vs Playwright Test

The same 29 tests, written three ways:

• JSON files run by swiftbrowse test (examples/e2e/tests)
• hand-written TypeScript with the SDK under node:test (bench/e2e/sdk)
• idiomatic Playwright Test with a setup project and fullyParallel (bench/e2e/specs)

They cover forms, filtering, hover menus, back and forward, reloads, target=_blank and popup tabs, same-site, cross-site and nested iframes, file upload, network mocking (data, errors, aborts, delays, times, POST checks) and a saved login.

All three used the same app server, the same Chromium headless-shell binary, and Playwright Test 1.64.0. Each run is a whole CLI command, start to exit, as CI runs it. The table shows the median of 5 interleaved runs. At most workers tests run at once in every tool. "First run" means no warm browser was running, which is what a fresh CI job gets. Every suite passed on every run.

Where the time goes: Playwright Test starts Node, transforms the test files and starts a browser per worker. SwiftBrowse is a native process whose sessions attach to warm browsers in milliseconds. Much of the remaining time is the demo app's own deliberate waits (120 ms to add an item, 150 ms to sign in, 600 ms in the loading-state test), which no tool can skip.

cd bench && npm install && node e2e.mjs ../target/release/swiftbrowse

#Agent tasks vs Playwright MCP

The benchmark drives SwiftBrowse MCP and Playwright MCP 0.0.83 over the same transport (MCP stdio), the way an agent does: take a snapshot, read element refs from it, act, confirm the outcome. Playwright MCP ran twice: with its defaults, and tuned with --timeout-settle 0, its best case. Both used the same Chromium binary; medians of 15 iterations.

The KB column is how many bytes the tools returned into the agent's context. SwiftBrowse snapshots are bounded to 150 elements, so on the 400-row page the snapshot is smaller but doesn't contain row 250: the agent has to locate it, which the snapshot itself tells it to do.

cd bench && npm install && node agents.mjs ../target/release/swiftbrowse --iter 15 --cold 10

#Library operations vs Playwright

Identical tasks with the Playwright 1.64.0 library API and SwiftBrowse (through MCP over stdio), using the same headless-shell binary. p50 in ms:

With its own browser, cold start is at parity: both tools are bounded by Chromium's startup. SwiftBrowse does more work in some steps (fill reads the value back; navigate waits for client-rendered pages that are still empty).

cd bench && npm install && node bench.mjs ../target/release/swiftbrowse --iter 50 --cold 20