Browser Automation Benchmark: 8 Setups Tested on Amazon
We tested eight browser automation setups under the same proxy conditions. Six formed the leading statistical group. Stock Chromium recorded the highest observed page-delivery rate at 96%. Across those six setups, the test found little difference in Amazon page delivery.
Two setups performed worse in this configuration: CloakBrowser delivered pages in 80% of completed attempts, while Patchright reached 63%.
Commercial sites now process an enormous volume of automated traffic. Imperva reported that 51% of web traffic was automated in 2024, with bad bots accounting for 37% of all traffic. Akamai also recorded more than 25 billion AI-bot requests in commerce during July and August 2025.
For Amazon, the browser is only one part of a request. The target also sees the IP address, session, and request history. We therefore tested the complete access setup rather than a browser in isolation.
Try NodeMaven Residential Proxies with the $3.50 paid trial, including 750 MB of proxy traffic.
Quick Overview
- What we tested: 8 browser automation setups against Amazon product-search pages.
- What stayed the same: One Linux VPS, one test harness, the same NodeMaven gateway configuration, and a fresh sticky session for every attempt.
- What we found: Six setups were statistically tied in the leading group. CloakBrowser and Patchright had lower observed page-delivery rates.
- What the result suggests: A reliable proxy and session configuration can have a major effect on page delivery when several browser setups perform similarly.
Methodology: How We Tested Browser Automation on Amazon
The benchmark changed one main variable: the browser automation setup. The machine, target, gateway configuration, and session pattern stayed the same.
The workload used 500 Amazon product-search queries. It ran on one 2-vCPU Linux VPS with one process and a headful virtual display. Every attempt received a new sticky proxy session through the NodeMaven gateway, configured with country=any, filter=medium.
The run produced 3,816 Amazon attempts and 3,816 distinct session IDs. Resource blocking, humanized input, and timezone or locale alignment were disabled. Those choices keep the test narrower and easier to reproduce, but production setups may need different settings.
This benchmark compares eight browser automation setups under the same NodeMaven proxy conditions. It does not compare proxy providers.
The findings also apply to one Amazon workload. Google, Bing, DuckDuckGo, and other websites use different conditions and should be tested separately.
Compare Eight Browser Automation Setups
The report tested a mix of browser runtimes, patched browser builds, and automation approaches. Stock Chromium was the control setup.
| Настройка | Tested Implementation |
| Stock Chromium | Playwright Chromium with no patches; the control setup |
| Rebrowser | Playwright setup with the Runtime.enable leak patched |
| Botasaurus | Chrome automation through a scraping framework |
| Camoufox | Patched Firefox controlled with Playwright |
| Zendriver | Chrome control through raw CDP |
| SeleniumBase | SeleniumBase UC setup |
| CloakBrowser | CloakBrowser’s patched Chromium setup |
| Patchright | Playwright setup with automation signals patched |
The eight setups use different approaches to browser automation, but this benchmark evaluates one shared outcome: Amazon page delivery under the same test conditions.
For a separate overview of browser automation tools and their common use cases, see our guide to browser automation tools.
What Counted as a Delivered Amazon Page
We did not judge the result by the HTTP status code alone. A request could return a response without giving the scraper a usable Amazon page.
An attempt counted as delivered only when it produced usable Amazon content. The benchmark tracked refusals, empty pages, CAPTCHAs, and test-harness errors separately.
Of the 3,816 Amazon attempts, 286 had harness errors and were excluded from the page-delivery comparison. The remaining 3,530 completed attempts produced 3,107 delivered pages.
How We Analyzed the Results
We compared each setup against the others with a two-sided Fisher test. Because eight setups create many pairwise comparisons, the analysis used a correction to reduce false positives.
This method separates meaningful performance gaps from small differences that can appear between test runs.
The results describe one Amazon workload, run on one machine during a defined test window with the same NodeMaven gateway configuration.
Results: Six Setups Form the Leading Group
The overall page-delivery rate was 88%. The results fall into two groups rather than eight ranked positions.
| Result group | Настройка | Amazon page-delivery rate | Completed attempts |
|---|---|---|---|
| Leading group | Stock Chromium | 96% | 436 |
| Leading group | Rebrowser | 95% | 440 |
| Leading group | Botasaurus | 94% | 444 |
| Leading group | Camoufox | 92% | 446 |
| Leading group | Zendriver | 92% | 404 |
| Leading group | SeleniumBase | 92% | 464 |
| Lower observed result | CloakBrowser | 80% | 439 |
| Lower observed result | Patchright | 63% | 457 |
Why 96% Does Not Make Chromium the Winner
Stock Chromium recorded the highest observed page-delivery rate at 96%. Rebrowser followed at 95%, Botasaurus at 94%, and Camoufox, Zendriver, and SeleniumBase at 92%.
The statistical analysis placed all six setups in the same leading group. Chromium came first in the observed results, but the benchmark did not establish a clear performance advantage over the other five.
What the Lower Results Show
CloakBrowser and Patchright performed worse than the six leading setups in this Amazon test. CloakBrowser delivered usable pages in 80% of completed attempts, while Patchright reached 63%. Both results were statistically lower than the leading group.
For a team that needs consistent Amazon page delivery, those gaps are substantial. CloakBrowser failed to deliver a usable page in roughly one out of five attempts. Patchright failed in more than one out of three.
What the Results Mean for Web Scraping Teams
The six leading setups took different technical paths yet reached comparable delivery rates. A high-quality proxy layer and stable session design deserve the same attention as the browser automation setup.
How Proxy Quality Can Make or Break Browser Automation
Each setup used the same NodeMaven gateway settings and a fresh sticky session for every attempt. The six leading setups used different browser runtimes, patches, and control methods, yet all delivered Amazon pages at similar rates.
That result makes the shared connection environment hard to ignore. Clean IPs, accurate geo-targeting, and stable sessions support more consistent browser automation. Amazon sees the browser profile, IP address, session, and request history behind every request.
This benchmark does not compare NodeMaven with other proxy providers, however it shows that six different browser automation setups delivered strong results under the same NodeMaven residential proxy conditions.
Choose Browser Automation for Your Workflow
Pick a setup that your team can run and debug without friction. Existing code, programming language, browser actions, and operational experience usually deserve more weight than a few percentage points from one study.
Then test the complete workflow on the target you plan to collect from. Match the geography, session duration, request pace, and page types you expect in production. Measure usable delivered pages, not HTTP responses alone.
Some teams prefer a locally operated framework. Others want a hosted environment that combines browser control and proxy infrastructure. Our comparison of scraping browsers explains that second option. If you are building an Amazon workflow, our guide on how to use an Amazon scraper covers the implementation side.
Run Browser Automation With NodeMaven
Use High-Quality Proxies With Your Existing Browser Setup
Low-quality or heavily reused IPs can disrupt a browser automation workflow before the script has completed its first action. NodeMaven screens residential IPs through its IP-фильтр качества before assignment, removing lower-quality and higher-risk IPs from the available pool.
For browser automation, Резидентские прокси NodeMaven support country, state, city, ISP, and ZIP-code targeting. You can rotate IPs for larger workloads or keep the same IP with sticky sessions of up to seven days when a workflow needs continuity.
NodeMaven proxies work with Playwright, Puppeteer, Selenium, and other tools that support HTTPS или SOCKS5 connections. Clean IPs and stable sessions give your browser automation a more reliable starting point.
Try NodeMaven Residential Proxies with the $3.50 paid trial, including 750 MB of proxy traffic.
Use Scraping Browser for Fully Managed Automation
The benchmark tested locally controlled browser automation setups. NodeMaven Браузер для скрейпинга offers a fully managed cloud-browser option for teams that do not want to operate their own browser infrastructure.
Scraping Browser includes high-quality NodeMaven residential and mobile proxies, browser fingerprinting, proxy configuration, CAPTCHA solving, and cloud browser infrastructure. You can connect your existing Playwright, Puppeteer, or Selenium scripts to the managed browser.
Choose the proxy location, select rotation or sticky sessions, and run the automation through NodeMaven’s managed environment. This option fits teams that want to focus on browser actions and data extraction without maintaining browser fleets, fingerprints, and a separate proxy layer.
Try NodeMaven Scraping Browser with the $3.50 paid trial and 750 MB of proxy traffic. Pay for proxy usage only, no separate browser fee.
