How to Estimate Your Monthly Residential Proxy Bandwidth Needs

On a per-GB residential proxy plan, bandwidth is the unit you buy, so picking the right plan comes down to one question: how many gigabytes will you actually use in a month? Guess too low and you hit overage or throttling mid-month; guess too high and you overpay for headroom you never touch. The good news is that bandwidth is estimable, not a mystery. With one formula, some realistic per-page sizes, and a five-minute measurement, you can size a plan with confidence.

This guide is for teams planning proxy usage. We’ll build the estimate step by step, ground it in a real measurement, and walk through worked examples for common workloads.

The formula

Everything reduces to this:

Monthly GB  ≈  (requests per month  ×  avg response size  ×  overhead factor)  /  bytes per GB

Four inputs, and one of them dominates. Let’s take them in order of impact.

Step 1: average response size (the big driver)

How many bytes come back per request is where estimates live or die, and it swings by more than 10x depending on how you fetch. Typical ranges:

The single biggest factor in your bill is whether you render a full browser or fetch HTML/JSON directly. A browser downloads everything on the page; a plain HTTP request pulls a fraction of that. If you can get your data from the HTML or an API, your per-request size, and your bandwidth, drops by an order of magnitude. (That, plus asset-blocking, is the core of how to cut proxy bandwidth costs.)

Don’t guess this number if you can measure it, see Step 4.

Step 2: requests per month

This is usually pages (or records) times frequency:

requests per month  =  items  ×  checks per day  ×  30

A price monitor tracking 10,000 products once a day is 10,000 × 1 × 30 = 300,000 requests a month. A one-off dataset build is just the total page count, no frequency multiplier. Include pagination: if each “item” spans three pages of results, multiply accordingly.

Step 3: the overhead factor

Real crawls aren’t 100% efficient. Retries, redirects, and failed attempts all cross the proxy and all cost bandwidth, a blocked or timed-out request still spent bytes. Add an overhead factor on top of your clean estimate:

• Easy, open targets: ~1.1 (10% overhead)
• Typical sites: ~1.2 (20%)
• Well-defended targets (frequent blocks/retries): ~1.3 or higher

The harder the target, the more retries, so the higher the factor. Reducing your block rate (better IP quality, sane pacing) directly shrinks this, see how to avoid getting blocked.

Step 4: measure your real per-page size (don’t guess)

The fastest way to a trustworthy estimate is to fetch a representative sample of your actual target through the proxy and measure the bytes. The response size in bytes is len(response.content):

import os, requests, statistics

USER, PASS = os.environ["SHIFTER_USER"], os.environ["SHIFTER_PASS"]
proxy_url = f"http://{USER}-country-us:{PASS}@p.shifter.io:443"
proxies = {"http": proxy_url, "https": proxy_url}

sample_urls = [ ... ]   # 20-50 representative target URLs
sizes_kb = []
for url in sample_urls:
    r = requests.get(url, proxies=proxies, timeout=30)
    sizes_kb.append(len(r.content) / 1024)

avg_kb = statistics.mean(sizes_kb)
print(f"avg {avg_kb:.0f} KB/request  (n={len(sizes_kb)})")

Run it against 20 to 50 real URLs and you have a grounded average size instead of a guess. Note this measures the compressed bytes that actually cross the proxy (keep Accept-Encoding on), which is what you’re billed for. Full client setup is in residential proxies with Python.

Worked examples

Using Monthly GB = requests × avg_size × overhead / 1,000,000 (KB to GB, decimal):

Price monitoring, HTML-only. 10,000 products, daily, ~200 KB/page, overhead 1.15. 300,000 × 200 KB × 1.15 = 69,000,000 KB ≈ 69 GB/month.

Same job, but full browser rendering. ~2 MB/page instead of 200 KB. 300,000 × 2,000 KB × 1.15 = 690,000,000 KB ≈ 690 GB/month. Same data, 10x the bandwidth, that’s the cost of rendering when you didn’t need to (see with Playwright for blocking assets if you must render).

Search/rank monitoring, lean responses. 500 queries, 4x/day, ~30 KB each, overhead 1.2. 500 × 4 × 30 × 30 KB × 1.2 = 2,160,000 KB ≈ 2.2 GB/month. Small and cheap.

One-off dataset build. 2,000,000 pages, ~300 KB HTML, overhead 1.2. 2,000,000 × 300 KB × 1.2 = 720,000,000 KB ≈ 720 GB, one time, not monthly.

The pattern is clear: response size and rendering choice dominate; request count scales linearly; overhead is a modest multiplier.

From estimate to plan

Turn the number into a plan with a little discipline:

• Add a buffer. Size the plan to your estimate plus 20 to 30%, for growth within the month and estimation error. Running out mid-cycle is more disruptive than a little headroom.
• Know the overage terms. Check how your provider handles going over, extra per-GB, throttling, or a hard stop, so a busy month doesn’t surprise you.
• Reconcile weekly. Compare actual usage against your estimate early in the cycle and adjust. Real usage teaches you your true per-page size and block rate faster than any guess.
• Shrink the number before you buy more. Often the cheapest gigabyte is the one you don’t spend, skip rendering, block assets, and don’t re-fetch unchanged pages (cut proxy bandwidth costs) before upsizing the plan. This is the per-GB model that makes efficiency pay (the per-port era is over).

FAQ

How do I estimate bandwidth if I’ve never run the job? Measure a representative sample of your target pages through the proxy (Step 4) to get a real per-request size, then plug it into the formula with your request count and an overhead factor. A measured sample beats any generic estimate.

What uses the most bandwidth? Full browser rendering, by far, it downloads every image, font, and script. Fetching HTML or a JSON API directly can cut per-request size by 10x. Rendering choice is the biggest lever on your bill.

Do failed and retried requests count toward my bandwidth? Yes. Any request that crosses the proxy uses bandwidth, including blocks, redirects, and retries. That’s why the estimate includes an overhead factor, and why reducing your block rate lowers cost.

Is 1 GB 1,000 MB or 1,024 MB? It depends on the provider’s billing definition, decimal (1,000) or binary (1,024). The difference is about 7%, fine for estimation, but confirm which your provider uses when sizing close to a plan boundary.

How much buffer should I add? Plan for your estimate plus 20 to 30%, to absorb growth and estimation error within the month. Then reconcile against real usage and adjust, rather than over-buying up front.

The bottom line

Estimating residential proxy bandwidth isn’t guesswork: multiply requests by a measured average response size and an overhead factor, convert to GB, and add a buffer. The two things that move the number most are how you fetch (HTML/JSON beats full-browser by roughly 10x) and how often you retry (better IP quality means fewer wasted bytes), so measure a real sample before you commit, and cut the number before you buy more.

Once you have an estimate, the pricing page lays out the per-GB plans so you can match a tier to your number plus buffer, and point a well-tuned scraper at the residential gateway to keep actual usage close to plan.