How much proxy bandwidth does a scraping job need?

Estimate decimal gigabytes (GB) for the permitted workload using the client settings, redirects, retries, and browser resources that the job will actually use. Keep the result as a range until a representative sample can be compared with the provider's billing meter.

This is a planning model. The values below are labelled assumptions. This is not a provider benchmark and contains no ProxyLane measurement.

Define the unit that consumes traffic

Define the unit that consumes traffic: one product page, one search result, an authorized browser checkout, or one API response. Count the pages or records in the next run, then record the client and request behavior.

Keep the target, parser, browser or HTTP client, headers, session policy, and concurrency fixed during measurement.

A bandwidth estimate from a command-line document request does not represent a browser journey.

Use a range model, not one precise number

For a first forecast, state each assumption and use decimal GB. Define base_bytes as the document response plus response headers for one initial attempt.

Apply an asset multiplier only when the document was measured separately and browser resources need to be modelled. For a measured full browser journey, use its total and set the multiplier to 1 to avoid counting assets twice.

forecast_gb =
  work_units × base_bytes_per_initial_attempt × asset_multiplier × retry_multiplier
  ÷ 1,000,000,000

Set asset_multiplier to 1 for a document-only client or a browser run whose full resource total is already measured. For a document-only sample, it represents extra browser resources in the model.

Set retry_multiplier to 1 plus the expected extra attempts. Include redirects and failed requests when the provider bills them. Otherwise, model them separately and confirm the provider's billing rule.

Each scenario assumes 1,000 work units. The base sample includes the document and response headers; the asset and retry multipliers are shown explicitly.

These worked assumptions show the arithmetic; they are not measurements of a target, client, or provider. Replace them with a representative sample before choosing a package.

For a long-tailed workload, carry low, expected, and high cases into procurement instead of averaging away heavy pages.

Caution: Measurement runs consume real traffic. Set request and spend caps before sampling, use an authorized test workload, and stop at the first breached limit. Use a sandbox when available; otherwise follow an approved production test procedure.

Measure the client that will run the job

For an HTTP client, log request headers, response headers, and body bytes for a permitted sample. Keep redirects and retries as separate rows. Record whether the forecast includes request uplink bytes.

Requests documents per-request proxy configuration and timeout behavior. Its response body length is not a provider invoice. A proxy can count bytes differently from the application, and a provider may apply minimums or bill failed attempts.

For a browser, collect resource timing after the page settles. Record resource type and URL host in a redacted log.

MDN defines PerformanceResourceTiming.transferSize as response headers plus payload. It can be 0 for cache hits or cross-origin resources without Timing-Allow-Origin. Treat it as a client-side observation, not a complete measure of uplink bytes or the provider's billing meter.

Playwright can monitor HTTP and HTTPS traffic and configure a proxy globally or per browser context in its network documentation. Use that instrumentation to count resources required by the acceptance rule. Decide whether analytics, third-party fonts, video, prefetches, and service-worker traffic belong in the forecast. Record the rule so later runs remain comparable.

Make retries visible in the estimate

A retry is work, even when the final record is accepted. Keep these values separate:

A timeout may have no body but still use connection and request traffic. A target can return a response that the parser rejects.

Do not estimate only from successful records or present one retry ratio as a provider success rate. The ratio describes this workload, client, and period.

Reconcile the estimate before buying

Run a small permitted sample, then compare three totals:

1. The client-side transferred bytes, split by request headers, response headers, body, asset, redirect and retry
2. The expected decimal GB after any unit conversion, with uplink included or excluded by an explicit rule
3. The provider’s reported or invoiced usage for the same window and its documented billing boundary

Investigate the difference before scaling. Common explanations include compression, cached resources, cross-origin timing gaps, background requests, DNS or TLS retries, provider rounding and resources fetched outside the proxy. Keep page content and credentials out of general telemetry. The proxy monitoring playbook shows how to separate gateway, target and validation evidence.

This forecast answers a pre-purchase question. The cost per successful request guide covers post-run cost after retries, compute, and support time. Use both calculations so a low traffic estimate is not mistaken for low cost per useful result.

Bring the sample size, low/expected/high GB range, geography, session behavior, retry rule, and billing questions to the provider.

The ProxyLane pricing page, checked 2026-09-25, lists the 1 TB package at USD 2.50/GB. Smaller tiers have higher per-GB rates. The offer includes HTTP and SOCKS5 and non-expiring traffic.

Confirm package terms and the billing meter against the workload. Registration is free, and the traffic package is selected during onboarding. Create an account to begin setup.

ProxyLaneTraffic never expires

Premium residential proxies
From $2/GB

Scale your workflows with the tools you already use. Rotating or sticky sessions up to 72 hours.

Try 350 MB for $1.95 View plans