Define what a successful request means
A fast response is useful only when it contains the data you intended to collect. Before comparing providers, write down the target pages, the expected region, the required content and the timeout for each request. A response with a successful HTTP status can still be a login page or an empty result.
Keep a small representative set of sources. Include a normal detail page, a larger page and any rendering requirement that matters to the project. Use that same set for each candidate so that a lighter page does not give one provider an accidental advantage.
Keep the setup consistent
Record where the test client runs. A test from a US server describes that route; it does not describe the route from every user or region. Keep the client location, request method, timeout, concurrency and response checks consistent within a comparison.
Define latency before you collect results. For example, measure from the start of the request until the complete response body has arrived. If a different test measures only time to first byte, store that in a different column rather than mixing the two.
- Provider and region: record the candidate label and the requested location for each attempt.
- Outcome: distinguish usable content from timeouts, connection failures and unsuccessful responses.
- Latency: record positive milliseconds for requests that meet your success rule.
- Test conditions: keep client location, target set and concurrency with your test notes.
Compare reliability alongside latency
The analyzer in this hub groups records by provider and region. The success rate is successful requests divided by all recorded requests. Its mean, P50 and P95 calculations use successful requests only, so a failure does not become a misleading zero-millisecond response.
P50 is the median by the nearest-rank method. P95 selects the value at position ceil(0.95 × n) in the sorted successful measurements. With a very small dataset, P95 may simply be the slowest successful result. Treat a short pilot as an initial observation, and include the sample size when discussing it.
Example: the supplied sample has four attempts for Sample A, with three successes. Its success rate is 75%. The failed attempt stays in the denominator but has no successful latency measurement.
Use a simple recording format
provider,region,status,latency_ms
Candidate A,US,ok,420
Candidate A,US,timeout,
Candidate B,US,ok,510The tool accepts ok, success and HTTP 2xx as successful outcomes. It counts failed, fail, error, timeout and HTTP 3xx–5xx as unsuccessful. If your collection follows redirects, record the final checked outcome rather than an intermediate redirect. Additional columns may carry notes, but they are not included in the summary.
Set the decision rule before the pilot
Write down the minimum usable-content rate, acceptable latency range, geographic requirement and expected bandwidth. Compare observed results with those requirements. Keep the raw results so that a later run can be reviewed against the same baseline.
Open the benchmark analyzer or download the CSV template. The browser tool summarizes measurements you provide; it does not create connections to proxy servers.