Web Data Frontier Benchmark: the September 2026 run

Results

The run in detail

The original post makes the case for the benchmark. A request passes when it returns a 2xx status and the body contains text found only on the real page, such as a product title or a listing address. A 200 carrying a challenge page or an empty JavaScript shell fails. Each provider gets five attempts per target, with a 90-second timeout.

The latency score is failure-aware. On each target, a provider that returned the page scores the nearest-rank p75 of its successful attempts. A provider that never returned it takes the p75 of the providers that did, and a target nobody returned scores the 90-second timeout. The score is the mean across targets, so failing fast does not make a provider look fast.

Six providers take the proxy pool as a request parameter: ScraperAPI, ScrapingAnt, Scrapingdog, ZenRows, Decodo, and Scrapfly. Their adapters pin the top pool. The other 10 choose the bypass server-side, so their adapters show only part of the configuration. String is one of them: its adapter sends no tier or configuration flag, so String’s result reflects its default routing. JS rendering stays off wherever the caller controls it, except for ZenRows and Decodo, whose adapters predate that rule. Apify runs through its Web Fetch Actor.

What we noticed

Speed is where this run moved. On the 82 sites where both String and Firecrawl got the page at least once, our median attempt was faster on 70 of them. In August it was 54 of 82.

The gap between our fastest and slowest attempt on the same URL shrank too. Its median fell by more than half, to 2.4 seconds. What’s left is concentrated: ten sites carry about half of it, and on most of them the pattern is a few quick attempts and one or two very slow ones. On ashleyfurniture.com, three attempts took under two seconds and two took almost a minute.

The biggest lesson for anyone testing vendors is setup. ScrapingBee went from last in August to seventh, and most of that came from how we call it. If you test vendors on your own list, configure each one the way its vendor documents, or part of what you’re measuring is your own configuration.

Results by source

Wherever String returned all five attempts, at least one other provider did too. What separates providers is the short list of sites that most of the field could not return in full. On the 13 sites where four or fewer of the 16 providers returned every attempt, String did so on eight: mouser.com, bestbuy.com, skyscanner.net, autozone.com, us.louisvuitton.com, indeed.com, cargurus.com, and axs.com. On mouser.com, 10 of the other 15 providers returned nothing. String returned every attempt on skyscanner.net, a site it failed outright in August, and three other providers did the same.

Firecrawl, fourth by requests passed, returned every attempt on more sites than any provider except String: 75, against 71 each for Scrapfly and ScraperAPI. It also returned nothing at all on 17 sites, against 5 for Scrapfly and 9 for ScraperAPI, which is what puts it below them on the leaderboard.

No provider returned temu.com. On idealista.com, which String returned on every attempt in August, the String API returned HTTP 502 all five times, while Scrapfly, ScraperAPI, Apify, and Oxylabs returned it on every attempt. String returned four of five on yelp.com, autotrader.com, coupang.com, allegro.pl, and footlocker.com, and on each of those at least one other provider returned all five.

The largest retail sources did not separate the field: 12 of the 16 providers returned every attempt on walmart.com, and 14 on target.com.

The table groups the 100 sites into the 16 verticals they were drawn from, easiest first inside each. A cell counts the attempts that returned the real page, out of 5. Latency is left out of the cells, because a provider that never returned a site has no measured latency there.

What changed since August

The target set grew by one site, buybuybaby.bedbathandbeyond.com, to 100. Two targets, safeway.com and zara.com, now point at different product pages than in the August run. Apify joined the field, and no provider left. The latency definition is unchanged.

Before this run, we checked every adapter against its vendor’s documentation for bot-protected pages and changed five: ScrapingBee, ScraperAPI, Scrapfly, Scrapingdog, and Nimble.

The two largest rises came with adapter changes. ScrapingBee moved from JS rendering on its default proxy pool to Auto Mode, which picks the pool and rendering itself, capped at 75 credits a request. ScraperAPI moved from a bare request to its ultra_premium tier with caching off. Scrapingdog fell after its adapter added stealth mode.

The ZenRows and ScrapingBee figures for August include attempts that never measured a target. The ZenRows API returned HTTP 402 (payment required) on all 245 attempts against the last 49 targets in suite order. The ScrapingBee API returned HTTP 401 (unauthorized) on all 55 attempts against the last 11 targets in suite order.

String and Scrapfly held first and second. ScraperAPI rose from tenth to third, Firecrawl held fourth, and Apify entered at fifth. Context.dev fell from third to eighth and Bright Data from fifth to sixth.

String’s success rate did not move. Its latency score fell from 9.98s to 7.06s. Firecrawl, the fastest provider in August at 9.21s, posted 9.11s.

Where providers specialise

DataDome, Akamai, Cloudflare, and PerimeterX guard 63 of the 100 targets between them.

String was first or tied for first against all four, including PerimeterX, its weakest group in August at 88.9%. Scrapfly tied it on DataDome at 92.6%. The one anti-bot group where String trailed was Kasada, three sites, where Apify and Zyte returned every attempt and String returned 93.3%.

Bright Data and Context.dev split sharply by vendor. Bright Data returned 100% of PerimeterX attempts and 47.4% of DataDome; Context.dev 96% of Cloudflare and 43.2% of DataDome. A target list heavy in DataDome sites would put both well under their overall rates.

Eight of the targets are social platforms. String, Scrapfly, Bright Data, and Browserbase returned every attempt on all eight. Firecrawl returned HTTP 403 on every attempt against six of them: reddit.com, linkedin.com, instagram.com, facebook.com, tiktok.com, and pinterest.com. Browserbase, a hosted browser, returned 8% of attempts against Cloudflare.

By vertical, String trailed in two. In real estate, three providers finished ahead of String’s 85.7%: Scrapfly at 100%, Firecrawl at 97.1%, and Apify at 100%. In marketplaces and classifieds, Scrapfly at 98% finished ahead of String’s 96%.

Run it yourself

The harness, the 100 target URLs, the pass criteria, and every provider’s adapter are public, and the repository takes your own API keys. This run’s raw results record every attempt, including the error each failure returned. A full run makes thousands of billable calls, so start with a subset. If your numbers differ from ours, open a pull request.

The current leaderboard lives at the benchmark page, which moves with every run. This post stays as published.

Cheers,
String team