Performance Benchmarks

Wraith Browser makes specific performance claims. This page backs each one with measured results, explains the methodology, and gives you everything you need to reproduce the numbers on your own hardware.

Claims and Evidence

Important distinction: The ~50 ms claim refers to engine-internal page fetch time. The CLI round-trip (wraith-browser navigate <url>) includes process startup and Tokio runtime initialization, which adds ~100-200 ms of overhead. When running via the MCP server (the normal production path), this startup cost is paid once, not per request.

Methodology

What these benchmarks measure

The CLI benchmarks measure end-to-end wall-clock time including:

• Process startup and Tokio runtime initialization
• Engine creation (Sevro native engine)
• HTTP fetch, TLS handshake, response parsing
• DOM construction and snapshot generation
• Process shutdown

The MCP server benchmarks measure the engine-internal time by sending requests to a long-running server process, eliminating per-request process startup.

What these benchmarks do NOT measure

• JavaScript execution performance (QuickJS is used, not V8)
• Visual rendering or screenshot accuracy
• WebSocket or streaming performance
• Performance under proxy or FlareSolverr configurations

Honest reporting principles

1. No warmup hiding — warmup runs are counted separately and clearly labeled
2. Percentiles over averages — p95 and p99 show tail latency, not just the happy path
3. Failure counting — failed requests are tracked and reported, not silently dropped
4. Network included — real network latency is included; HTTP is not mocked
5. System info recorded — CPU, RAM, and OS are logged with every run

Test Environment

Hetzner CX22 (primary benchmark target)

The headline numbers come from a Hetzner CX22 — a commodity VPS that anyone can spin up in minutes:

Network conditions

All benchmarks run against real public websites over real network connections. We do not mock HTTP responses or use localhost by default. This means latency numbers include DNS resolution, TLS handshake, and internet round-trip time.

For isolating engine performance from network variability, the benchmarks support a local HTTP server mode — see the Reproduce It Yourself section.

Test URLs

Benchmarks use a curated list of public sites grouped by complexity:

These sites tolerate modest benchmark traffic without rate limiting.

Results

Latency

Measured on the Hetzner CX22 with 100 iterations per URL, 3 warmup runs discarded.

The average page load of 180 ms from the 1,000-session test includes network latency to diverse targets. Engine-internal time (HTTP + parse + snapshot) is typically 30-80 ms for most pages.

Memory

Measured via RSS of the MCP server process on the Hetzner CX22.

Per-session memory converges to approximately 8 MB as session count increases. The baseline process overhead (~80-120 MB) is amortized across sessions.

Throughput

Measured on the Hetzner CX22 during the 1,000-session benchmark.

Detailed pages/second measurements at varying concurrency levels: run bench_concurrent.sh on your own hardware — results depend heavily on network conditions. See Reproduce It Yourself.

Token Savings

This is one of Wraith's most important metrics for AI agent use cases. Every token sent to an LLM costs money, and raw HTML is extraordinarily wasteful. All numbers below are measured, not estimated — token counts use the approximation of 1 token per 4 characters.

Production pages (job boards, real-world sites)

These are the pages that matter for production workloads. Job boards, e-commerce, and content-heavy sites are where raw HTML bloat is most extreme.

Lightweight test pages

Smaller, cleaner pages see lower savings — and very small pages can actually be larger in snapshot format due to @ref metadata overhead.

The pattern: Token savings scale with page complexity. Clean static HTML sees modest savings (30-70%). Real-world production pages with CSS, JS bundles, tracking scripts, and framework boilerplate see 77-99% savings.

Financial impact at scale

At $3/M input tokens (GPT-4 class pricing), an AI agent processing 3,000 Indeed job listings:

For a Lever/Greenhouse career page scraping workflow hitting 1,000 pages:

At scale — agents crawling, monitoring, or running agentic workflows hitting thousands of pages per day — the difference between raw HTML and Wraith snapshots is the difference between a viable product and a cost-prohibitive one.

Head-to-Head: Wraith vs Playwright (Chromium)

We ran a direct comparison on the same machine, same URLs, same conditions. No cherry-picking — every URL result is shown. The benchmark script is in the repo at benchmarks/bench_vs_playwright.js.

Test environment: Windows 10 Pro, Node v24.13.1, Playwright latest, Wraith 0.1.0 CLI mode. 5 iterations per URL. Chrome processes killed before start for clean memory baseline.

Latency Comparison (p50 ms)

Analysis: Playwright wins on small/fast pages because Wraith's CLI mode pays ~200ms process startup per invocation. In MCP server mode (the normal production path), this startup cost is paid once. Wraith wins decisively on heavier pages — 2.3-2.5x faster on the-internet.herokuapp.com — where Chrome's rendering pipeline adds overhead that Wraith's native parser avoids entirely.

The honest story: For raw single-page latency, Playwright is competitive or faster on lightweight pages. Wraith's advantage is at scale — 50, 100, 1000 concurrent sessions — where per-session overhead dominates, and via MCP server mode where startup cost is amortized.

Memory Comparison (measured, not estimated)

Measured via RSS with zero Chrome processes at baseline. Playwright spawns chrome-headless-shell.exe processes.

Wraith memory measured in CLI mode (per-process). MCP server mode uses ~8 MB/session with shared process overhead amortized.

At 50 sessions: Playwright uses 6x more memory than Wraith CLI, and 8.5x more than Wraith MCP server mode.

Projected to scale:

A workload that requires a 68 GB instance with Playwright fits on a $4/mo Hetzner CX22 with Wraith.

Where Chrome is still better

Wraith does not replace Chrome for every use case. Chrome-based tools are the better choice when you need:

• Full visual rendering — pixel-perfect screenshots of complex CSS layouts, PDF generation with visual fidelity
• Heavy JavaScript SPAs — single-page apps with complex client-side routing and framework-specific rendering that depend on V8's full JS engine
• Chrome-specific Web APIs — WebRTC, WebGL, Service Workers, and other APIs not implemented in Wraith's Sevro engine
• Cross-browser visual testing — Playwright's multi-browser support for UI regression testing

For the vast majority of automation work — navigating pages, extracting content, filling forms, managing sessions, and feeding data into AI agents — Wraith handles it at a fraction of the resource cost.

Reproduce it yourself

cd wraith-browser
npm install --prefix benchmarks playwright
npx --prefix benchmarks playwright install chromium
cargo build --release
node benchmarks/bench_vs_playwright.js

Results are saved to benchmarks/results/ as JSON.

Reproduce It Yourself

All benchmark scripts are in the repository. Clone, build, and run:

git clone https://github.com/suhteevah/wraith-browser
cd wraith-browser
cargo build --release

Run individual benchmarks

export WRAITH_BIN=./target/release/wraith-browser

# Latency: 100 iterations per URL, reports p50/p95/p99
./benchmarks/bench_latency.sh

# Memory: RSS at 10, 50, 100, 500 sessions
./benchmarks/bench_memory.sh

# Concurrency: throughput at 10, 50, 100, 500, 1000 sessions
./benchmarks/bench_concurrent.sh

# Token savings: raw HTML vs Wraith snapshot per URL
./benchmarks/bench_tokens.sh

Results are written to benchmarks/results/ with timestamps.

Customize the runs

Isolate engine performance from network

To remove network variability, run benchmarks against a local HTTP server:

echo '<html><body><h1>Benchmark</h1><p>Test content.</p></body></html>' > /tmp/bench.html
cd /tmp && python3 -m http.server 8888 &

TEST_URL=http://localhost:8888/bench.html ./benchmarks/bench_latency.sh

Hardware requirements for reproducible results

• 4+ CPU cores (concurrent benchmarks need headroom)
• 8 GB RAM (memory benchmark at 500 sessions needs ~6 GB)
• Stable network connection (wired preferred over Wi-Fi)
• Linux (scripts use /proc, ps -o rss, date +%s%N)

Close other heavy applications and run multiple times for consistent results.