What Is Bandwidth in Proxy Services?

In proxy pricing, bandwidth means data volume, not connection speed. When a plan says "50 GB," that is the amount of data you may push through the proxy in a billing period, counting every byte in both directions: your outbound HTTP request (headers plus body) and the inbound response (the page, JSON, or file you asked for). Providers reset the counter monthly and either stop you, throttle you, or bill an overage rate once you cross it.

The response body dominates. A typical GET request with normal headers is well under 2 KB, while the response can be anything from a 5 KB JSON payload to a 2 MB rendered product page. On most scraping workloads the response is 85 to 95 percent of consumed bandwidth, and protocol overhead (TCP handshakes, TLS negotiation, proxy headers) makes up the rest.

There are two dominant metering models, and knowing which one you are buying changes how you budget.

Per-GB (metered pool). You buy a bucket of gigabytes, and every byte drains it. This is the standard for residential, ISP, and mobile proxies, because the provider pays for the underlying data those networks consume. Rates fall with volume: a 1 GB starter tier might run $8/GB while a 100 GB tier drops to $3/GB. This model fits bounded, predictable jobs where you can estimate consumption in advance.

Unlimited-per-port (throughput model). Instead of a data bucket you rent a port or a fixed number of concurrent threads, and you push as much data through each port as you can. Datacenter providers offer this because their bandwidth comes from bulk server-hosting contracts that do not scale in cost with data volume. Here is the catch most buyers miss: "unlimited bandwidth" almost always means unlimited data on a capped number of ports or threads. Your ceiling is concurrency, not gigabytes. If you need to understand how those port and thread limits translate into real request rates, see our guide to concurrent connections in proxies.

So when you compare a $5/GB residential plan against an "unlimited" datacenter port, you are comparing two different units. One prices the data, the other prices the pipe. For a deeper look at how datacenter plans structure this, read datacenter proxy pricing models.

Four things drive your bill, and only one of them is obvious.

Page weight. The median web page transfers about 2.6 MB of data with all assets loaded, per the HTTP Archive Web Almanac (2024). If your scraper loads pages the way a browser does (images, CSS, fonts, JavaScript bundles), 2 to 2.6 MB per page is a fair baseline.

Images and assets. For most scraping jobs, images, fonts, and stylesheets are pure waste: you want the text, not the hero photo. On an image-heavy retail page, media can be 60 to 80 percent of the transferred bytes. Blocking those requests is the single biggest lever you have.

Retries and failed requests. A 403, a 429, or a timeout still transfers data. Error pages, redirects, and CAPTCHA challenges all count toward your total even though they deliver nothing useful. At a realistic 10 to 20 percent failure rate on a tough target, that is a 10 to 20 percent tax on your bandwidth that naive estimates ignore.

Protocol overhead. TLS handshakes and proxy-layer framing add a few percent on top of raw content. Providers that meter at the TCP layer (including TLS bytes) report 3 to 8 percent higher consumption than providers counting only successful HTTP response bodies. Neither is wrong, but knowing which your provider uses keeps your estimates aligned with the dashboard.

The insight buried here: bandwidth is charged on the whole response, not the part you keep. Scrape a 900 KB product page for one price field and you paid for 900 KB. Extracting server-side or blocking assets at the proxy layer is what turns that around.

Different proxy types are built on different networks, so their bandwidth economics differ.

Datacenter proxies win on cost per gigabyte and raw throughput, which suits high-volume collection of simple, static targets. Residential and mobile proxies cost more because the provider pays for data on real home and cellular connections, and that premium buys detection resistance. If those categories are new to you, start with what a residential proxy is and how datacenter proxies work.

The practical takeaway: match the proxy type to the byte. Push heavy, tolerant workloads through cheap datacenter or per-port bandwidth, and reserve metered residential gigabytes for requests that genuinely need a residential IP.

Estimate before you buy so you do not land exactly at your cap with retries still pending. The formula:

Total GB = average response size x request count x (1 + retry rate) x (1 + overhead)

Worked example. You plan to scrape 100,000 product pages, each averaging 400 KB after you strip images, with a 12 percent retry rate and 10 percent overhead:

• Base: 100,000 x 400 KB = 40,000,000 KB, which is about 38 GB
• Retries: 38 GB x 1.12 = about 43 GB
• Overhead: 43 GB x 1.10 = about 47 GB

Buy a plan that covers 55 to 60 GB, not 40. The gap between the naive base figure and the real number is where overage bills come from. Use this per-request table to pick your average response size:

For jobs measured in millions of requests, bandwidth planning becomes inseparable from rate-limit planning; our guide to scraping high-volume data without rate limiting covers how to size both together.

Cutting bandwidth lowers your bill and stretches a fixed plan further. The techniques stack.

Block images, fonts, and stylesheets. If you only need text, do not download the media. In a headless browser you abort those resource types:

# Playwright: skip images, media, fonts, and CSS to cut bandwidth
def block_assets(route):
    if route.request.resource_type in {"image", "media", "font", "stylesheet"}:
        return route.abort()
    return route.continue_()

page.route("**/*", block_assets)

This alone can drop per-page bandwidth 60 to 80 percent on media-heavy targets.

Do it at the proxy layer. With SparkProxy's Scraping API you can strip assets and skip rendering server-side, so the heavy bytes never reach your infrastructure. render_js=false returns plain HTML instead of a full browser render, and block_resources and block_ads drop images, fonts, media, and tracking scripts:

curl -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode "url=https://www.sparkproxy.io/" \
  --data-urlencode "render_js=false" \
  --data-urlencode "block_resources=true" \
  --data-urlencode "block_ads=true"

If you need only a few fields, extract_rules returns just those values as structured data, so you pay for the fragment you keep rather than the whole document.

Prefer targeted requests over full pages. If a target exposes a JSON endpoint returning the same data as its rendered page, use it. A JSON response is often 1 to 5 percent of the HTML page's size.

Turn on compression. Send Accept-Encoding: gzip, br. Brotli responses run 20 to 40 percent smaller than uncompressed HTML, and nearly every server supports it.

Cache stable data and deduplicate. Category trees, product IDs, and reference data that rarely change should not be re-fetched every run. Filter already-collected URLs before the job starts, since re-scraping pages you already hold is pure waste.

Retry smart, not hard. Back off on 429s, and separate retryable errors (timeouts, 503s) from permanent ones (404s, 410s). Blind retry loops can double the bandwidth of a struggling job.