Benchmarks / Methodology
Benchmark local and remote CDP latency
Run a timing script that records attachment, navigation, failures, and environment metadata.
This is a reproducible measurement procedure, not a published performance result. The script below compares CDP attachment and a small navigation workload against browser allocations you supply. It does not allocate browsers, measure model reasoning, or rank providers.
Define the question first
A local-versus-remote comparison includes at least two network paths: client to browser, and browser to website. Report both locations. If the local browser visits a nearby website while the remote browser uses another region or proxy, navigation time reflects more than CDP overhead.
Use a dedicated test allocation. The script creates and closes its own fresh context for each run, leaving existing tabs alone. Your runtime must permit context creation. It disconnects the client at the end of each run; release the allocation separately through your provider's documented mechanism.
Download and run
Download the CDP timing script. Place it in a Node.js project that has Playwright installed. Use the same pinned client version for both environments.
# Set REMOTE_BROWSER_CDP_URL securely before running.
# For the local baseline, set it to a dedicated local CDP endpoint.
RUN_LABEL=local CLIENT_REGION=your-region BROWSER_REGION=your-region \
RUNS=30 node cdp-latency.mjs > local.json
# Change REMOTE_BROWSER_CDP_URL to your dedicated remote endpoint.
RUN_LABEL=remote CLIENT_REGION=your-region BROWSER_REGION=runtime-region \
RUNS=30 node cdp-latency.mjs > remote.jsonThe default target is a public example page. Set TARGET_URL to a controlled page for stronger repeatability. Keep that URL free of credentials and use a target you are authorized to test. A nonzero exit means at least one attempt or cleanup step failed; the JSON still retains the samples.
What the script records
| Metric | Boundary |
|---|---|
| attachMs | Starting the CDP connection until the client attaches |
| contextMs | Creating a context and page |
| navigationMs | Navigation until DOMContentLoaded with an accepted HTTP response |
| titleReadMs | Reading the page title after navigation |
The report includes per-run samples, HTTP status where available, failed phases, cleanup failures, browser and client versions, regions supplied by the operator, and p50/p95 using nearest rank over successful attempts. It omits credential-bearing endpoints and exception text.
Limitations to publish with results
Thirty serial attempts are an initial check, not a capacity test. The browser process remains allocated between runs, so attachment timing does not include cold startup. Fresh contexts do not eliminate browser-level cache, host scheduling, DNS effects, or target-site variability. The script does not validate application-specific task success, authentication reuse, downloads, or agent decisions.
Record host capacity, browser display mode, proxy settings, allocation policy, target content version, and any warm-up policy alongside the output. Alternate local and remote batches if network conditions vary. Report failure rate next to latency; never silently remove failed attempts or compare only the best run.
For full workflow studies, add a fixed task, a measurable success condition, model and prompt versions when applicable, and separate allocation and release timings. Publish the raw reports and script version with any claim. See the benchmark methodology, local vs remote comparison, and resource usage guide.