Benchmark · August 2026
Before writing a line of the product we built a measurement rig and pointed it at 29 real sites — news, travel, SaaS, docs, e-commerce — from two different networks with three browser configurations. 232 renders later the answer was not the one we expected.
Every URL was rendered under each configuration and the resulting PNG was classified automatically, not by eye: a render counted as a failure if it errored or timed out, and as unusable if a detector found a consent wall, a bot challenge or a blank page covering the capture.
The overlay detector went through three iterations before it was trustworthy. Bounding-box geometry flagged pages that were fine; hit-testing the centre of the viewport missed consent iframes, because they compute a transparent background and the scrim above them sets pointer-events: none. What finally held was shape: position: fixed, actually painted or containing an iframe, and a high effective z-index.
A control group of clean pages ran alongside the polluted ones the whole way, for the obvious reason — a detector that finds an overlay on everything is not a detector.
93% of renders returned an image. Only 69% returned an image you could put in front of someone. That 24-point gap is the entire product: it is invisible to any status-code-based monitoring, and it is the number no screenshot API quotes.
Seven of the 29 URLs came back dominated by a cookie or consent overlay. Exactly one was stopped by bot protection. The industry talks almost exclusively about the second problem and ships nothing for the first, which is seven times more common.
A patched, fingerprint-hardened build scored identically to plain headless Chromium on the same corpus. Not marginally better — the same. We had assumed this was where the advantage would come from, and it is the assumption the spike was worth running to kill.
On the hardest sites a residential line scored 90% where a datacenter address scored 70%. Where a render is called from turned out to matter more than how convincingly the browser lies about itself — which is also why we do not promise to get past everything.
One Chromium process handing out a fresh browser context per render cost 146MB per concurrent render against 206MB for a process each — about 30% less for the same isolation, since a context is already the boundary that separates cookies, storage and cache.
p50 across the corpus. The long tail is real and it is mostly other people's JavaScript: one documentation site took 75 seconds before we put a hard deadline on every render.
| Decision | Why |
|---|---|
| Overlay removal became the product, not a flag | It is on by default, and the landing page compares it against off rather than describing it. |
| The stealth engine was dropped | It measured as no better and would have been a dependency, an attack surface and a maintenance cost for nothing. |
| Every render got a hard deadline | 45 seconds, enforced above the per-step timeouts, because a slot held open is a slot no paying request can use. |
| Bot protection is reported, not faked | Where a page cannot be rendered you get an error. An image of a challenge screen is a failure that looks like a success. |
The comparison on the landing page runs live against whatever URL you type, with no key and no signup, and returns the same two renders this benchmark classified — the page as it loads, and the page with the overlays taken off.