Short answers
How much data does one scraped page use?
Measure the page with your own client. An HTTP fetch and a browser visit can request different resources, and compression, caching, uploads and redirects change the total. There is no page-size preset that reliably describes every target.
How many requests fit in 1 GB?
Divide 1,000,000,000 bytes by your measured average transfer per request. For illustration, 100,000 bytes per request gives 10,000 requests before extra attempts or headroom. That size is an example, not a measured average for a particular task.
Do failed requests and retries consume traffic?
An attempt can transfer bytes before it fails. Include those bytes in your sample, and count extra attempts when forecasting. If your measured average already includes retries for each completed job, do not add the same retries again.
How do I reduce proxy bandwidth in a headless browser?
Record which resources the page requests, then remove only the ones your task can do without. Compare the same workflow before and after the change and check that its result is still correct. The reduction depends on what that page loads.
Do unused GB expire?
A purchase adds to your balance. The current validity rule is printed beside the price ladder below and on the pricing page; check it when choosing an order size.
How do I check how much I have used?
The dashboard and GET /v1/traffic show gb_total, gb_used and gb_left. Usage refreshes every five minutes, so allow for that delay when comparing a test run with the account meter.
Can I calculate an estimate without writing code?
Use the proxy bandwidth calculator linked below. Enter your request count and average transferred bytes, then choose any extra attempts and headroom. The pricing calculator converts a chosen whole-GB order into a price.
Already have a request count and a measured transfer size? Open the proxy bandwidth calculator. Continue here for how to collect those inputs and check the result.
What to include in the estimate
Include traffic sent and received through the proxy. A response-body size alone leaves out uploads and headers. Redirects, additional browser resources and partial transfers can also contribute. For a description of the account meter, see what counts as proxy traffic.
Choose one counting unit and keep it throughout. If you count HTTP requests, measure bytes per request. If you count complete page loads, measure all the requests that each page load makes. Multiplying page loads by the size of one resource misses the rest of the page.
Measure your actual workflow
- Choose a sample covering the page types or endpoints in the job. Include uploads, redirects and failures that occur during the run.
- Keep the client, compression, cache, session and resource-loading settings consistent with the planned job. Separate samples are useful when those settings differ.
- Record total transferred bytes and the number of requests or page loads. Divide the total by that count to get the mean. Use the same counting unit in your forecast.
- Keep a note of whether the mean includes retries. Repeat the sample when the target or workflow changes, and compare runs before choosing headroom.
For a browser check, open DevTools before the run. Chrome reports both transferred data and loaded, uncompressed resources; use the transferred figure when estimating network traffic. It only covers requests recorded while DevTools is open. See the Chrome Network reference.
For automated checks, Playwright request.sizes() exposes request and response header sizes, request-body bytes and encoded response-body bytes. These client counters help explain a run. They do not establish the exact account charge: missing or failed transfers and connection overhead need separate attention. Reconcile the sample with the account meter.
One 200 MB download: what it measured
On 3 October 2026, one HTTPS download through the HTTP proxy retrieved the first 200,000,000 bytes of a file from the OVH test endpoint. The request used HTTP Range 0-199999999, with certificate verification enabled and no automatic retries. The downloaded file size was checked and the test data discarded.
| Recorded field | Result |
|---|---|
| Downloaded body and checked file size | 200,000,000 bytes = 200 MB = 0.2 GB in decimal units |
| curl transfer time | 35.192607 seconds |
| Average payload rate | 45.464 Mbps for this transfer |
| HTTP result | CONNECT 200; destination 206 Partial Content; curl exit 0 |
| Country verification | Not verified |
The first test endpoint refused the download with HTTP 403 after CONNECT succeeded. No download-body bytes were recorded there, and it was not retried automatically. A different public test endpoint supplied the ranged transfer above. Success at one destination does not establish access or performance at another.
This measures one downloaded payload over one route at one time. It is not a page-size sample, a promised proxy speed or proof that the account was billed exactly 0.2 GB. Requests, headers and other traffic have different counting boundaries. For a price tracker, sample the actual permitted workflow and compare refreshed account usage as described below.
The formula
Estimated bytes = (initial requests + extra attempts) × mean bytes per attempt. Multiply by (1 + headroom) if you want an allowance for variation. This assumes the mean represents both initial and repeated attempts; split them into separate totals if their sizes differ substantially.
These inputs illustrate the calculation. They are not observed page sizes or recommended retry and headroom settings.
initial_requests = 50_000
extra_attempts = 5_000
bytes_per_attempt = 60_000
headroom = 0.20
estimated_bytes = (initial_requests + extra_attempts) * bytes_per_attempt
planned_bytes = estimated_bytes * (1 + headroom)
planned_gb = planned_bytes / 1_000_000_000
print(f"{planned_gb:.2f} GB") # 3.96 GBHere, 5,000 extra attempts for 50,000 initial requests means 10 extra attempts per 100 initial requests. A failure percentage alone does not tell you how often the client retries. Use the extra attempts your retry policy and sample actually produce. If the request count already includes every attempt, enter no additional retries.
This calculation uses decimal units: 1 kB = 1,000 bytes, 1 MB = 1,000,000 bytes and 1 GB = 1,000,000,000 bytes. A GiB is 1,073,741,824 bytes. Convert a KiB or MiB measurement to bytes first rather than treating it as kB or MB. The definitions are listed by NIST.
Three examples with fictional inputs
| Assumed workload | Calculation | Estimate |
|---|---|---|
| 50,000 initial requests, 5,000 extra attempts, 60,000 bytes per attempt, 20% headroom | 55,000 × 60,000 × 1.20 ÷ 1,000,000,000 | 3.96 GB |
| 2,000 requests per day for 20 days, 50,000 bytes each, no extra attempts or headroom | 2,000 × 20 × 50,000 ÷ 1,000,000,000 | 2 GB |
| 10,000 complete page loads, mean 800,000 bytes per load already including retries, no headroom | 10,000 × 800,000 ÷ 1,000,000,000 | 8 GB |
The final example already includes retries in the per-page mean. Adding a retry multiplier would count them twice. Likewise, a total request count across all workers should not be multiplied by the worker count again.
Change the workflow, then measure again
- Remove image, media or font requests only when the workflow does not need them. Keep a passing baseline so you can check the result after each change.
- Reuse cached data where it remains valid for the task. Measure with the cache behaviour you will use in the full run.
- Limit retries and investigate repeated failures. Follow the destination’s usage rules and stop when access is refused.
- Check the transfer total after making a change. A smaller number is useful only if the workflow still returns the information you need.
The browser bandwidth guide covers request interception. For connection setup, use the Playwright guide or Python Requests guide.
Compare the estimate with account usage
Record the account usage before an isolated run and again after the next usage refresh. Keep unrelated traffic off the same credentials during that comparison. Divide the change by your completed workload count to estimate the account usage per job, including the retries that run actually made.
Usage refreshes every five minutes. Compare refreshed readings, not an immediate before-and-after pair.
curl --silent --show-error --fail-with-body \
"https://api.portproof.org/v1/traffic" \
--header "Authorization: Bearer $PORTPROOF_API_KEY"
# Read gb_used before the run and after the next refresh.Client counters and the account meter have different measurement boundaries. A difference is a reason to check the sample, units, redirects, retries and other activity; it does not identify one cause on its own. Use the measured account change to refine the next estimate.
Turn the estimate into an order
| Order size | Per GB | Saving |
|---|---|---|
| 1 to 4 GB | EUR 4.50 | |
| 5 to 24 GB | EUR 3.90−13 % | |
| 25 to 49 GB | EUR 3.50−22 % | |
| 50 to 99 GB | EUR 3.20−29 % | |
| 100 to 249 GB | EUR 2.90−36 % | |
| 250 GB and more | EUR 2.50−44 % |
GB never expire. What you buy stays on your balance until you use it; a new purchase adds to the same balance. The trial is 0.5 GB for EUR 2.90, once per customer.
The price tier applies to the amount in one order.
Use the bandwidth calculator to forecast traffic, then the pricing calculator to price a whole-GB order. Keep the unrounded estimate visible when choosing an amount. A headroom allowance is a planning choice, not a guarantee that a run will fit.
For a first measurement, the paid trial and its current terms are on the shop page. Both mobile 4G/5G and residential use the same GB balance; measure with the pool and client settings the job will use.
What is not allowed
Use the estimate for work you are permitted to perform, such as price monitoring, market research or QA. Respect the destination’s usage rules and access restrictions. See the acceptable-use policy.