---
site: steel.dev
collection: blog
canonical_url: https://steel.dev/blog/remote-browser-benchmark
markdown_url: https://steel.dev/blog/remote-browser-benchmark.md
content_signal: ai-input=yes, ai-train=yes, search=yes
related:
  - https://steel.dev/blog/steel-vs-kernel.md
  - https://steel.dev/blog/steel-vs-browserbase-a-practical-comparison.md
  - https://steel.dev/blog/why-browser-agents-fail-in-production.md
title: Remote Browser Benchmark
description: How fast is "Hello, browser?"
date: 2025-11-07
authors:
  - JunHyoung Ryu
category: Comparisons
minutes: 4
tldr: Over 5,000 runs per provider on AWS EC2 us-east-1, a create, connect, visit google.com and release flow averaged 0.89s on Steel with a p95 of 1.09s, 1.70x to 8.95x faster on average than Kernel, Browserbase, Hyperbrowser and AnchorBrowser. Steel's control-plane cost (create plus release) was about 229 ms.
topics:
  - Remote browser benchmarks
  - Session startup latency
  - Control-plane overhead
  - Tail latency
  - Browser provider reliability
  - Browser automation for AI agents
entities:
  - Steel
  - Kernel
  - Browserbase
  - Hyperbrowser
  - AnchorBrowser
  - Playwright
  - CDP
  - AWS EC2
  - browserbench
answers_questions:
  - Which remote browser provider has the fastest session lifecycle?
  - How does Steel compare to Browserbase, Kernel, Hyperbrowser and AnchorBrowser on latency?
  - How much of a remote browser session's time is control-plane overhead?
  - What success rates did remote browser providers have over 5,000 runs?
  - How was the remote browser benchmark measured?
  - How can agent builders reduce browser session overhead?
---

# Remote Browser Benchmark

## TL;DR

- Our minimal “hello, browser” flow (create → connect → visit [google.com](http://google.com/) → release) averages **0.89s on Steel** with a **p95 of 1.09s** (AWS EC2, us-east-1).
- Versus other providers we tested, Steel’s end-to-end time is **1.70×–8.95× lower on average**, and **1.61×–10.62× lower at p95**.
- The **control‑plane tax** (create + release) on Steel is ≈**0.229s** (≈**25.6%** of total). Elsewhere it ranges **0.367s → 6.557s** (≈**21.9% → 82.0%** of total).
- For AI agents (e.g. browser-use), the **create/connect/release** flow happens **a lot**, so shaving seconds here compounds across long runs and many workers.

![](https://steel.dev/assets/framerusercontent.com/images/BeULtOdcsdMi6k8uoo2ChvYWIwM.png)

> *Fig.1. Mean total duration (ms)*

**Full code & raw results:** <https://github.com/steel-dev/browserbench>

## Why this benchmark matters?

Agents don’t just “do work” on pages; they **start and stop** browsers over and over: new identities, clean slates, anti-bot resets, concurrency fan-out.

If you save **\~1s per loop** and your agent runs **20 loops**, you’ve just won **\~20s** on a single task. Multiply that across **hundreds of workers** and **thousands of tasks/day** and you either delight users or grow a queue.

So we asked a simple question: *How fast is “Hello, browser?”*, and how much of the time is **control plane** (session creation/release) vs **data plane** (connect + navigate)?

## What we measured

Provider-agnostic, minimal lifecycle with each vendor’s SDK:

- **Create** a session (cold start / scheduling / identity)
- **Connect** the driver (CDP handshake)
- **Navigate** to `google.com` (waits for `domcontentloaded`)
- **Release** the session (cleanup, quotas, accounting)

**Environment:** AWS EC2 **us-east-1**\
**Runs:** 5000 per provider

**Steel runner (TypeScript, abbreviated)**:

```ts
const session = await client.sessions.create();
const browser = await chromium.connectOverCDP(session.cdpUrl);
const page = await browser.newPage();
await page.goto("https://google.com", { waitUntil: "domcontentloaded" });
await client.sessions.release(session.id);
```

> We used Playwright over CDP for all vendors and mirrored the same four steps with each provider’s SDK. We did not supply any provider‑specific configuration, sessions ran on each vendor’s default settings

## Results at a glance

### Total time (create → connect → goto → release)

| **Provider** | **Avg (ms)** | **Median (ms)** | **p95 (ms)** | **p99 (ms)** |
| - | - | - | - | - |
| **STEEL** | **894.13** | **867.0** | **1,090.0** | **1,340.05** |
| KERNEL | 1,518.53 | 1,485.0 | 1,752.10 | 1,992.04 |
| BROWSERBASE | 1,676.76 | 1,669.0 | 1,873.00 | 1,981.03 |
| HYPERBROWSER | 3,657.11 | 3,665.5 | 5,338.00 | 6,695.05 |
| ANCHORBROWSER | 8,001.29 | 7,919.0 | 11,561.00 | 13,957.14 |

![](https://steel.dev/assets/framerusercontent.com/images/tyWaeVbyvvalf2y4sCeRellzOOg.png)

> *Fig. 2. Total duration distribution (ms)*

**Steel speedup (avg / p95):**

- vs **Kernel**: **1.70×** / **1.61×**
- vs **Browserbase**: **1.88×** / **1.72×**
- vs **Hyperbrowser**: **4.09×** / **4.90×**
- vs **AnchorBrowser**: **8.95×** / **10.62×**

**Time saved for your agents (per 1,000 sessions):**

- **\~10.41 min vs Kernel**
- **\~13.05 min vs Browserbase**
- **\~46.06 min vs Hyperbrowser**
- **\~118.46 min vs AnchorBrowser** (\~1 hr 58 min)

> *Mind the tails. Some platforms show p99 spikes in the multi‑second range, the outliers users actually feel during bursts and autoscaling.*

### Where the time goes (stage breakdown)

| **Provider** | **Create** | **Connect** | **Goto** | **Release** | **Create+Release** | **% of Total** |
| - | - | - | - | - | - | - |
| **STEEL** | **181.57** | **174.64** | **490.29** | **47.62** | **229.19 ms** | **25.6%** |
| KERNEL | 261.10 | 428.90 | 533.95 | 294.57 | 555.67 ms | 36.6% |
| BROWSERBASE | 188.18 | 517.37 | 792.27 | 178.99 | 367.17 ms | 21.9% |
| HYPERBROWSER | 1,731.63 | 347.60 | 377.89 | 1,199.98 | 2,931.61 ms | 80.2% |
| ANCHORBROWSER | 3,796.55 | 184.29 | 1,259.66 | 2,760.79 | 6,557.34 ms | 82.0% |

![](https://steel.dev/assets/framerusercontent.com/images/K4uMK30s1aihkKdZEOmmQUpA8w.png)

> *Fig. 3. Control-plane cost (create + release) (ms)*

**Takeaways**

- **Absolute control-plane cost is smallest on Steel**: \~**229 ms**. That’s **1.6×** lower than Browserbase, **2.43×** lower than Kernel, **12.8×** lower than Hyperbrowser, and **28.6×** lower than AnchorBrowser.
- **Who’s dominated by control plane?** Hyperbrowser and AnchorBrowser (≈80% of total). Kernel’s control plane is material (≈37%). Browserbase’s control plane share is small (≈22%), but still **\~1.6×** Steel in absolute terms.
- **Data-plane (connect + first goto)**: Steel = **\~665 ms**. Kernel \~**1.45×**, Browserbase \~**1.97×**, AnchorBrowser **2.17×** of Steel. Hyperbrowser’s data-plane is close to Steel (**1.09×**), but its control-plane tax overwhelms it.

### Reliability (5,000 attempts/provider)

- **Steel**: **100%** success (0 failures)
- **Kernel**: **100%** success (0 failures)
- **Browserbase**: **99.96%** success (**2** failures)
- **Hyperbrowser**: **100%** success (0 failures)
- **AnchorBrowser**: **97.34%** success (**133** failures)

> Most SDKs perform **automatic retries** on certain errors (e.g., transient network, provisioning). Our “success” counts a run as successful **after retries**, so these rates may **overstate true first-attempt success** and **understate incident frequency**. Inspect per-stage error/retry telemetry in your traces for an accurate picture.

## Caveats

- This is a **cold lifecycle** for a single navigation. Real agents do auth, multi‑step forms, file uploads, and more.
- Results reflect **AWS EC2 us‑east‑1** and [google.com](http://google.com/) as the first page. Region, instance class, network and page choice influence numbers.

## Production guidance for agent builders

- **Amortize the handshake.** Batch multiple subtasks per session when safe, [reuse sessions](https://docs.steel.dev/overview/sessions-api/session-lifecycle) for longer flows.
- **Simplify the surface.** [**Mobile Mode**](https://docs.steel.dev/overview/sessions-api/mobile-mode) yields smaller DOMs and higher click accuracy for vision agents.
- **Watch the tails.** Track **p95/p99** per stage in your traces, optimize for outliers, not just averages.
- **Prefer headful when flaky.** **Headful Sessions** improve compatibility with sites that resist headless automation.
- **Debug faster.** **Agent Logs** give you action‑by‑action traces aligned to live view and MP4 replay.

## Build with Steel

Humans use Chrome. **Agents use Steel.**\
A headless browser API built for AI products: **fast session starts**, **persistent profiles**, **stealth & CAPTCHA**, **live viewers + MP4 replays**, and **scaling without the DevOps tax**.

- **Docs:** [https://docs.steel.dev](https://docs.steel.dev/)
- **Dashboard:** [https://app.steel.dev](https://app.steel.dev/)
- **Discord:** <https://discord.gg/steel-dev>
- **Full code & raw results:** <https://github.com/steel-dev/browserbench>
