What Proxy Performance Actually Means

Proxy providers publish latency figures and connection speeds. These measure how quickly the proxy infrastructure delivers a response — any response, including 403s, CAPTCHAs, and redirect loops. A proxy that blocks every request in 30 milliseconds is fast. It is not performing.

The metric that determines operational productivity is success rate: the fraction of requests that return the target content the workload requires. Success rate is determined by IP pool quality, proxy type match to the target's detection layer, and request structure — none of which are captured by a latency benchmark.

Latency measures the time path from client request to first byte of response. That path includes: client to gateway overhead, gateway processing and pool assignment, exit node to target routing (which is a function of physical distance between the exit IP's location and the target server's location), target processing time, and the return path. Most of this path is not under the proxy provider's control — the dominant variables are exit IP location relative to the target and the target's own server response time.

Success rate measures what fraction of requests return usable content. It is determined by pool quality on the specific target, proxy type fit to the target's detection layer, and request structure correctness. It has nothing to do with how fast the proxy delivers a response — a fast, clean residential IP from a well-managed pool can have lower success rate than a slower datacenter IP on a target that doesn't filter by ASN.

Throughput measures how many requests per unit time the operator can sustain before the target's rate limiting or the provider's concurrency ceiling becomes the binding constraint. Throughput is capped by two separate limits that operate independently: the provider's maximum concurrent connections, and the target's rate limiting threshold per IP or per session. Optimizing one without understanding the other doesn't increase throughput.

Latency is measurable with standard HTTP timing tools — time-to-first-byte against a known endpoint. The meaningful measurement is latency against the actual target from exit IPs in the required geographic segment, not against a provider-controlled test endpoint. Provider-published latency figures are typically measured against fast, nearby test servers — not against a target in a different region with variable server response times.

Success rate is not published by providers and must be measured directly. The measurement protocol: send N requests to the target through the proxy pool, count responses that return usable content versus blocks, CAPTCHAs, or errors. N must be large enough to account for pool rotation — a small sample may hit only clean IPs and overstate the actual success rate at scale. Running the measurement at the concurrency level the production workload requires surfaces rate limiting effects that low-volume tests miss.

Throughput ceiling identification requires separating provider-side from target-side constraints. If block rate increases with concurrency but not with request volume per session, the target's per-IP rate limiting is the constraint — changing proxy configuration (more IPs, shorter rotation interval) addresses it. If block rate increases with total request volume regardless of per-IP rate, the target has volume-level detection — the proxy architecture is not the variable.

Provider benchmark tests are run against endpoints without ASN filtering, rate limiting, or behavioral detection. Performance on these endpoints measures infrastructure quality — gateway overhead, routing efficiency, bandwidth capacity. It does not measure how the proxy performs against the targets the operator actually runs against. The benchmark-to-production gap is largest for hardened targets, which are exactly the targets operators use residential proxies for.

Latency benchmarks become irrelevant when success rate is low. If 60% of requests result in CAPTCHA challenges that the scraper can't solve, the speed of the remaining 40% doesn't determine productivity — the 60% failure rate does. Optimizing for latency before establishing minimum acceptable success rate is the wrong sequence.

Throughput figures from provider documentation describe the provider's infrastructure capacity — concurrent connections, bandwidth per account. They say nothing about the throughput ceiling the target imposes. Operators who provision high-throughput proxy accounts and run into target-side rate limiting at 10% of the account's capacity have the wrong constraint identified.

Datacenter proxies have lower latency than residential proxies for most target configurations. Exit infrastructure is in commercial facilities with high-bandwidth connectivity and consistent availability. Residential exit nodes are consumer devices on home connections — variable bandwidth, variable latency, higher jitter. For latency-sensitive workloads on targets that don't filter by ASN, datacenter proxies have better measured performance across all three metrics.

Residential proxies have higher success rates on targets that filter by ASN. The performance trade is not speed versus success — it is paying 5–15x more per GB for the success rate residential classification provides on hardened targets. On targets that don't filter by ASN, the success rate difference is zero and the cost difference is entirely waste.

Mobile proxies have the highest latency of any proxy type due to cellular network routing. They have the highest success rate on targets that specifically distinguish carrier ASN from residential ASN. The performance profile is: slowest delivery, highest IP-layer pass rate, highest cost. Appropriate only when the target's detection layer specifically requires carrier classification and no cheaper proxy type achieves acceptable success rate.