Spider Browser vs. Kernel vs. Browserbase: 999 URLs benchmarked

Note: This benchmark is maintained at Spider Research. Results below are the February 17, 2026 snapshot.

Kernel recently published a benchmark showing they’re 5.8x faster than Browserbase at creating browsers. Fast cold starts are a useful metric, but cold start speed doesn’t tell you whether your agent can actually get data from the page it navigated to.

We ran two benchmarks. First, the same kind of speed test Kernel used (session creation, page navigation, end-to-end latency) so you can compare directly. Then a harder test: 999 URLs across 254 domains and 18 categories, including sites behind the major bot-protection services. The result was a 100% pass rate with zero failures.

Everything is open source. You can reproduce every number in this post.

What Kernel measured vs. what we measured

Kernel’s blog compares cold start latency and end-to-end browser creation speed against Browserbase using browserbench, a third-party tool that times browser creation and basic page loads.

That answers one question: how fast can you get a browser? It doesn’t answer the questions that matter when your agent is doing real work:

• Can the browser bypass bot detection on protected sites?
• Does automation succeed across hundreds of different domains?
• What happens when a site serves a challenge page or blocks the first request outright?
• How fast is the full pipeline: connect, navigate, extract content, take a screenshot?

Our benchmarks cover both speed and reliability.

Speed benchmark

50 measured iterations (after 10 warmup rounds) using the spider-browser SDK, navigating to google.com and waiting for domcontentloaded. This mirrors the browserbench methodology.

All 50 runs succeeded, a 100% success rate, with zero failures and zero timeouts.

Session creation is 705ms at the median. That’s WebSocket connection, authentication, and full protocol init. The session is immediately ready to navigate with no cold start penalty, because Spider Browser connects to pre-warmed browser instances. Session release is instant; closing the WebSocket ends the session with no VM to tear down.

Total end-to-end: 2.5 seconds to connect, navigate, and close. Kernel claims 3.72x faster than Browserbase end-to-end, but neither publishes raw millisecond numbers for the full pipeline.

Reliability benchmark

Speed on google.com is one thing. Reliability across the real web is another.

We built a dataset of 999 URLs across 254 unique domains in 18 categories, from simple static sites to some of the most aggressively protected properties on the web.

The corpus

This isn’t a curated list of friendly sites. It includes the same domains that cause real failures in production agent workflows, and it spans three difficulty tiers, from static HTML to aggressive bot-protection services.

What we measured

For each URL: connect to a remote browser, navigate, wait for content to load, extract content, take a screenshot. A URL passes if it returns a non-empty page title and content body. There were no manual retries and no cherry-picked results.

Results

Every URL returned usable content. No timeouts, no blocks, no empty responses.

Timing

The median across all 999 URLs, including heavily protected sites like Amazon, Nike, and Booking.com, is 11.5 seconds from WebSocket handshake to extracted content and screenshot. The difficulty of the corpus pulls that number up. Easy and medium sites routinely finish in 1-3 seconds (the fastest completed in under a second). The slow tail (p95 at 39.3s) comes from the hardest anti-bot targets where the system works through multiple layers of protection to deliver real content.

These times are deliberate. Spider Browser waits for content to be ready: JavaScript rendering, lazy-loaded elements, dynamic content settling. We could return faster by skipping those checks, but you’d get incomplete data.

How the 100% pass rate works

Spider Browser handles anti-bot detection for you. When a page serves a challenge or block, the SDK detects it and escalates on its own. You don’t configure anything and you don’t write retry logic. You call page.goto(url) and get content back.

We built the entire stack in Rust. Sessions connect to pre-warmed browser instances with no cold start penalty. Each connection presents a unique browser profile, so consecutive requests to the same site look like different users to anti-bot systems.

The benchmark corpus deliberately includes some of the hardest targets on the web: Amazon, Nike, Best Buy, Walmart, Zillow, Sephora, Booking.com, and dozens of other sites behind major bot-protection services. All 999 URLs returned usable content.

What this means in practice

Kernel and Browserbase give you a browser. You write the automation, the anti-detection, and the retry logic. Spider Browser gives you the full pipeline:

import { SpiderBrowser } from "spider-browser";

const spider = new SpiderBrowser({
  apiKey: process.env.SPIDER_API_KEY,
  stealth: 0,
});

await spider.init();
await spider.page.goto("https://www.amazon.com/dp/B0DGJHM7QN");

const data = await spider.page.extractFields({
  title: "#productTitle",
  price: ".a-price .a-offscreen",
  rating: "#acrPopover .a-icon-alt",
  reviews: "#acrCustomerReviewText",
  availability: "#availability span",
  image: { selector: "#landingImage", attribute: "src" },
});

console.log(data);
// { title: "Apple AirPods Pro 2", price: "$189.99", ... }

extractFields() pulls structured data from the DOM in one call. For more complex workflows, there’s act() for click/type interactions, observe() for element discovery, extract() for natural-language queries, and agent() for fully autonomous multi-step workflows powered by any LLM.

Kernel optimizes for cold start speed. That matters when cold start latency is your bottleneck. For most agent workflows, the bottleneck is getting past bot detection, extracting content reliably, and handling failures across hundreds of different sites.

Reproduce it yourself

The dataset and full results are at github.com/spider-rs/spider-browser-dataset, including domains, URLs, timing breakdowns, and a machine-readable summary.

git clone https://github.com/spider-rs/spider-browser-dataset.git
cd spider-browser/typescript
npm install

# Full benchmark (999 URLs, ~19 min)
SPIDER_API_KEY=your-key npx tsx __tests__/stealth-test.ts --target=1000 --concurrency=25

# Quick test (200 URLs, ~4 min)
SPIDER_API_KEY=your-key npx tsx __tests__/stealth-test.ts --target=200

We also maintain 1,004 ready-to-use scraper scripts across 32 categories, each using the spider-browser SDK with field-level extraction. Clone the repo, set your API key, run.

• spider-rs/spider-browser: TypeScript, Python, and Rust SDKs
• spider-rs/spider-browser-dataset: benchmark dataset and results
• spider-rs/web-scraping-examples: 1,004 ready-to-use scrapers