Global Endpoint Latency Test

For each region the tool records performance.now() before and after a no-cors fetch to a small asset. The delta in milliseconds is the round-trip time including TLS handshake and one HTTP request. Multiple samples are averaged to reduce noise.

Either your proxy exit is geographically far from that region, or your ISP peers through a distant transit provider. Compare the direct row (proxy off) to the proxy row — if both are slow, the ISP is at fault; if only proxy is slow, the exit location is the issue.

They are a directional signal, not a full benchmark. Real scraping adds target-server response time, redirect chains and rate-limit backoff on top of the raw round-trip. Treat this tool's numbers as a minimum floor.

Run the test 3–5 times and take the median. Single samples are noisy — a single 800 ms outlier can hide a healthy 60 ms average. The tool preserves each run in the URL snapshot, so you can compare independent measurements.

Sub-60 ms is excellent (same-continent residential exits). 60–120 ms is good (cross-region residential). 120–200 ms is workable for asynchronous scraping. Above 250 ms will slow large sequential jobs materially — pick a different exit region.

No — only round-trip latency. High throughput requires many concurrent connections; this tool measures one small request per region. For throughput benchmarking, use the Bandwidth Calculator to estimate GB/mo and run a dedicated speedtest through the proxy.

Five reference regions: Ashburn (US-East), Frankfurt (EU-Central), London (UK), Singapore (APAC) and São Paulo (South America). Between them they cover the vast majority of scraping target datacenters.

Yes. The results are encoded into the page URL. Share the URL to reproduce the exact readings — helpful when comparing providers or filing a support ticket.

The default targets are region-representative CDN endpoints. For a specific URL, use the emitted cURL command from the cURL Generator with `-w '%{time_total}\n' -o /dev/null -s` and run it 10 times through your proxy — that's the truest per-target measurement.

The first request includes TCP handshake, TLS handshake and DNS resolution — usually 100–200 ms of one-time overhead. Discard the first sample or run the test 5+ times and use the median. Persistent connections reuse the tunnel and drop the overhead to near-zero after the first request.

Run the test through provider A, click Share to save the URL, switch to provider B, run again and Share. Open both URLs in adjacent tabs — the per-region numbers are directly comparable because targets, sample count and browser context are held constant.

Usually yes — residential exits add 20–60 ms because they route through the peer's home ISP and last-mile equipment. Datacenter exits sit inside major network POPs. For time-sensitive scraping, prefer datacenter or ISP-static; for anti-bot avoidance, accept the residential penalty.

Mobile exits typically show 40–100 ms higher latency than fixed-line residential because of radio scheduling and carrier NAT hops. In exchange, mobile IPs have the strongest anti-bot reputation for consumer-facing sites. Use this test to size the trade-off for your workload.

Yes — ad blockers, security extensions, and DevTools network throttling all add measurable overhead. For the cleanest reading, run the test in a fresh incognito window with extensions disabled and DevTools closed, connected through the proxy you're evaluating.