LATENCY
METHODOLOGY
Every latency figure on this site comes from one measurement, described in full below — including where it is weak. If a number appears anywhere on proxeasy.net without being traceable to this page, treat that as a bug and tell us.
WHAT WE
MEASURED
- REQUEST TYPE
- HTTP HEAD
- PAYLOAD
- 1 KB target
- SAMPLE SIZE
- 50,000 requests
- PERIOD
- 7 consecutive days
- STATISTIC
- p50 (median) round-trip time
- SCOPE
- End-to-end: client → ingress → exit → target and back
Summarised, that is: HTTP HEAD · 1 KB target · 50K samples over 7 days · p50.
THE NUMBERS
WE PUBLISH
All figures are end-to-end median round-trip time for a complete proxied request — not the time of any single leg.
| SCRAPER PLACEMENT | p50 RTT |
|---|---|
| Co-located with a Prox’Easy exit path (intra-region) | 38 ms |
| Unrelated US VPS, transit to Prox’Easy | 96 ms |
| Our residential network, no co-location | 120 ms |
| Residential via a typical competitor path | 178 ms |
BY ROUTE
| ROUTE | PROX’EASY | TYPICAL |
|---|---|---|
| US-East → US-West | 42 ms | 95 ms |
| US-East → EU-West (London) | 78 ms | 165 ms |
| US-East → São Paulo | 112 ms | 220 ms |
| EU-West → Singapore | 148 ms | 280 ms |
| Tokyo → Sydney | 105 ms | 190 ms |
| Intra-region (co-located VPS) | 38 ms | 120 ms |
WHERE THIS
MEASUREMENT IS WEAK
A benchmark without stated limits is marketing. These are the caveats we would raise if we were reading someone else’s numbers.
The baseline is a choice, not a constant.
“An unrelated US VPS” spans a very wide range. A host in the same facility as one of our exit paths can be close to the co-located figure; a host on the opposite coast is bounded by physics — roughly 42 ms of round-trip fiber between New York and San Francisco before any equipment is involved. 96 ms is representative of the hosts we sampled, not a universal constant.
p50 hides the tail, and the tail is where scrapers hurt.
These are median figures. A scraper’s throughput is often governed by p95 and p99, because slow requests occupy connection slots. We publish p50 because it is what we sampled consistently; treat it as a central tendency, not a worst case.
Latency is not the same as success rate.
A fast request that gets blocked is worth less than a slow one that returns data. Latency is one axis. For most scraping work, exit-IP quality decides whether the job completes at all.
Co-location is sufficient, not necessary.
Nothing about the first-leg saving requires PetroSky specifically. Any VPS with a short network path to the exit infrastructure gets a similar effect. We name a partner because customers ask us where to host, not because it is the only option — and Prox’Easy works identically from anywhere.
Connection reuse shrinks the benefit.
The first-leg saving is largest when a workload opens many short-lived connections, because every new TCP and TLS handshake costs round trips before any data moves. With HTTP keep-alive and a warm connection pool, the handshake cost is amortised and the advantage narrows. It does not disappear — every request still traverses the path — but the effect is smaller than a naive per-request multiplication suggests.
The saving is linear, not compounding.
Across N requests the total saving is N × the per-request delta. It adds up; it does not compound. We mention this because “compounding” is a common overstatement in this category and it is not what the arithmetic does.
RUN IT
YOURSELF
The script that produces the numbers above is a single Node file with no dependencies, and it works against any HTTP proxy — ours, a competitor’s, or none for your own baseline. It keeps every sample as one NDJSON line, so the summary can be recomputed by anyone who doubts it. MIT-licensed; the source is the download.
# download (Node 20+, nothing to install)
curl -O https://proxeasy.net/bench/run.mjs -O https://proxeasy.net/bench/lib.mjs -O https://proxeasy.net/bench/aggregate.mjs
# 500 samples, one per second, through your proxy
node run.mjs --proxy "http://user:pass@GATEWAY_HOST:PORT" --label my-4g --samples 500 --interval 1000
# the same, with no proxy — your baseline
node run.mjs --label direct --samples 500
# CSV: label, day, samples, errors, p50, p95, max, exit IPs, countries, ASNs
node aggregate.mjs bench.ndjsonWhat it measures: the round trip of an HTTP HEAD to a 1 KB target, from the first TCP connect to the response headers — the end-to-end figure in the table above — and, every fifty samples, the exit IP, country and network as reported by our IP tool. What it does not: bandwidth, success rate against any particular site, or anything a single client location cannot see. When we publish a run of our own exits, the raw file links from this section, dated.
WHY WE DON’T PUBLISH
COMPETITOR BENCHMARKS
We cannot test another provider’s network under controlled conditions — we do not control their account tier, their exit pool, or which of their PoPs we are routed through. Any number we published would say more about our test setup than about them. The “typical competitor path” row above is a measurement of a competitor path we sampled, not a claim about any named vendor’s best case.
This is also why our comparison pages compare billing models and access requirements — facts published by the vendors themselves — rather than performance we cannot verify.
Think we measured something wrong? Tell us — we would rather correct this page than defend it.