How much proxy bandwidth do you need? Pages per GB and cost

Pricing · Published November 2, 2026 · 10 min read

How much proxy bandwidth you need comes down to one multiplication: pages, times bytes per page, times a retry factor. Only the middle term swings. A mobile page loaded in a full browser has a median weight of about 2.2 MB, while the same page fetched as plain HTML is around 33 KB, so a 10,000-page job is either about 22 GB or about a third of a GB.

Short answer: multiply pages by kilobytes per page, divide by 1,000,000 to get GB, then multiply by your price per GB. At the median browser weight of 2,164 KB that's 462 pages per GB, or $2.60 per 1,000 pages at $1.20 per GB. A plain HTML fetch at 33 KB is 30,303 pages per GB.

How to calculate proxy bandwidth

Write it as GB = pages x KB per page x attempts per page / 1,000,000. That's the whole proxy bandwidth calculator. The rest of this article is about getting honest inputs. Pages comes from your job. Attempts per page comes from your logs, and a placeholder of 1.3 is more honest than 1.0, because nothing runs at 1.0.

KB per page is the term that moves by two orders of magnitude, and it moves on one decision. Do you load the page in a browser, or fetch the document with a plain HTTP client? Everything below is built around that choice.

One unit trap first. By the SI prefixes, 1 GB is 10^9 bytes, and the binary unit, 2^30 or 1,073,741,824 bytes, is a gibibyte (GiB), as NIST's reference on prefixes spells out. Vendors don't all follow that, and the gap is 7.4 percent, so check which one yours uses. Every calculation here assumes 1 KB is 1,000 bytes and 1 GB is 1,000,000 KB. The usage bar in our dashboard divides bytes by 1,073,741,824, so on that readout a GB is the larger unit. When you reconcile a test run, compare against the readout, not against your own decimal math.

How big is a web page?

The best public yardstick is the HTTP Archive's Web Almanac page weight chapter. We used the 2025 edition, whose trend data runs to July 2025, and checked it on 2 November 2026. On mobile, the 10th percentile of page weight is 516 KB, the median is 2,164 KB and the 90th percentile is 8,337 KB. Desktop runs heavier at 607, 2,412 and 9,179 KB.

Two cautions. The chapter's figures don't line up perfectly across sections: one paragraph puts the median mobile home page at 2,362 KB and another at 2.56 MB, and its HTML median is 22 KB in one place and 33 KB in another. Treat every number here as good to roughly 10 percent. Second, the Almanac measures what browsers download, which is not what your script downloads unless you run a browser.

Each median is taken separately, so rows don't sum to the total. Video, audio and other types make up the rest. Shares are our arithmetic.

Images alone are 36 percent of the bytes and JavaScript is another 25. Fonts and CSS are small by comparison. HTML, the one thing a plain fetch returns, is under 1 percent of the median browser load in this table. And weight is lumpy: one mobile page in ten carries at least 4,799 KB of video on its own.

Pages per GB and cost per 1,000 pages

Here's the arithmetic for a 10,000-page job at the Residential price of $1.20 per GB. Pages per GB is 1,000,000 divided by KB per page, rounded down. The HTML-only row is our derivation: we took the Almanac's 33 KB median mobile HTML document and treated it as the entire response. It is an estimate from these assumptions, not a measurement, and it leaves out headers and handshakes, which come back in later sections.

Assumes 1 GB = 1,000,000 KB, one attempt per page, and no header or TLS overhead. Browser rows use mobile page weight from the Web Almanac 2025.

The spread is the point. The same 10,000 pages cost $0.40 or $25.97, about 66 times apart, depending on what you download. Per 1,000 pages that's $0.04 against $2.60. Nothing about the proxy changed between those rows.

The price per GB scales the bill the same way. This is the median browser job, 21.64 GB, and the HTML-only job, 0.33 GB, across the four tiers we sell.

Cheapest per GB isn't automatically cheapest per useful page. A datacenter IP that a site refuses returns a small error page and a retry, and you pay for both. Which pool fits the target is a separate question, covered in residential vs datacenter proxies.

HTML only versus a full browser load

A plain HTTP client, whether curl, Python requests or a Go or Node fetch, asks for one URL and gets one document back. It doesn't parse the document, so it never requests the stylesheets, scripts, fonts or images the document points at. A headless browser requests all of them, plus whatever the scripts fetch after they run. That's where the 66-times gap comes from.

HTML-only isn't the right default for every target, though. If the data you want is built in the browser by JavaScript, the raw document won't contain it. Test that before you decide. Fetch the document and search it for a value you can see on the page. If it's there, you're done.

If it isn't, open Chrome DevTools, go to the Network panel, and filter by Fetch/XHR (the filter buttons are described in the DevTools network reference). Look for a JSON response that carries the data. Calling that endpoint directly typically costs a fraction of rendering the page around it, but the fraction depends on the site and we don't have a sourced average. Measure it.

Compression, headers, TLS and retries

Bandwidth is billed on bytes over the wire. With HTTPS through a proxy the gateway can't read the encrypted payload, so what it counts is whatever travelled, compressed or not. That's our inference from how a tunnel works, not a vendor statement, so confirm how yours counts. MDN's compression guide says size reductions of up to 70 percent are possible for some documents, and that already-compressed formats such as JPEG and video shouldn't be compressed again. Browsers send an Accept-Encoding header on their own. A raw HTTP client may not, so look at the headers yours sends. With curl, add --compressed.

The Almanac's Lighthouse text-compression audit passes on 71 to 72 percent of home pages, which leaves over a quarter that don't. If the target serves uncompressed text, there's nothing you can do on the client except know it when you estimate.

Headers count too. Per curl's manual, size_download is the body only, size_header is the downloaded headers and size_request is what you sent. A header block with a few cookies and a long policy header can run a kilobyte or more. On the 33 KB case, 1 KB of headers is 3 percent. On the 2,164 KB case it's nothing.

TLS adds a fixed cost per new connection. Wormly's SSL test page says a handshake payload of around 4 kB seems fairly typical, mostly the certificate chain (see its note on handshake size). A rotating gateway sends consecutive requests out of different exit IPs, so you can't count on a connection to the target being reused. We haven't measured this ourselves, so use one handshake per request as a planning ceiling. On a 33 KB document, 4 KB is 12 percent. On the median browser load it's about 0.2 percent. HTTP/1.1 connections are persistent by default, per MDN, so inside a sticky session you can pay that cost once if your client keeps the connection open.

Redirects are full requests. An http to https hop plus a trailing-slash hop can triple the request count on a tiny page, and each hop carries its own headers. Fetch the final URL directly where you can.

Retries and blocks are the big one. A 403 or a CAPTCHA page still downloaded bytes, and the retry downloads them again. Say 30 percent of pages need a second attempt. Attempts per page is 1.3, and the median job goes from 21.64 GB to 28.13 GB, or $33.76 at $1.20. The 1.3 is a placeholder, not a measurement. Work out yours as total requests divided by pages kept.

Targeting can change the multiplier too. The dashboard states that city, state, ZIP and ASN filters count bandwidth at 2x, and country targeting isn't in that list. A city-targeted median job counts as 43.28 GB, which is $51.94 at $1.20. Only add a narrow filter when the target needs it.

How to measure your own job before you buy

Don't trust our table, or anyone's, over your own sample. Twenty URLs is enough for a first estimate if they match the real job. Different page types, not twenty copies of one category page.

1. Pick 20 URLs that look like your real workload, and include a couple of the heaviest ones.
2. Fetch each through the gateway with curl and record size_download, size_header and size_request. The script below does it. The sum of the three is the bytes of that exchange.
3. Open the same pages in a browser with DevTools on the Network panel and Disable cache ticked. The bar at the bottom totals what was transferred since DevTools opened.
4. Take the mean and the 90th percentile of each set. Those are your two KB-per-page numbers, HTML-only and browser.
5. From a short trial run, compute attempts per page: requests sent divided by pages kept.
6. Compute pages x KB x attempts / 1,000,000, add 20 percent headroom, and compare the result against the dashboard's usage readout after a small pilot.

while read -r url; do
  curl -s --compressed -L --max-time 30 -o /dev/null \
    -x http://proxy.tierproxy.com:823 -U 'USERNAME:PASSWORD' \
    -w '%{size_download} %{size_header} %{size_request} %{num_redirects} %{http_code} %{url_effective}\n' \
    "$url"
done < urls.txt | tee sizes.txt

awk '{ total += $1 + $2 + $3 } END { printf "%d bytes over %d URLs, %.1f KB each\n", total, NR, total / NR / 1000 }' sizes.txt

Measure 20 URLs through a proxy. Replace USERNAME:PASSWORD with the credentials from your dashboard, and put one URL per line in urls.txt.

The loop doesn't see the TLS handshake. Add roughly 4 KB per request if each one opens a fresh connection, or let the pilot settle it. The readout in the dashboard is the number that matters, so compare against it. Before the pilot, run the credentials through the proxy checker to confirm they connect.

Ways to cut GB, ranked by effect

Ranked by how many bytes each can plausibly remove. The first two dwarf the rest.

1. Don't render. Fetch the document, or the JSON endpoint behind it. On the table's numbers, 33 KB against 2,164 KB is about a 98 percent cut, if the data is in the HTML.
2. Block images, media and fonts when you do have to render. Images are 36 percent of the median mobile home page in the Almanac's numbers, so blocking them takes the median job from 21.64 GB to 13.85 GB (estimate, shown below).
3. Skip pages you already hold. Store the ETag and send If-None-Match. Per RFC 9110 section 15.4.5, a 304 response is terminated by the end of the header section and can't contain content. It only helps on re-crawls of pages that haven't changed, and only where the server sends validators.
4. Cut wasted retries. Back off instead of hammering, and stop retrying a URL that returns the same block twice.
5. Send Accept-Encoding from raw clients, so text arrives compressed.
6. Hold one connection open per host inside a sticky session, so the handshake is paid once.

Here is the blocking in Playwright. The Playwright network docs show the image case with route.abort(), and the set below extends it to media and fonts. The docs also show the proxy launch option used here.

import { chromium } from 'playwright';

const BLOCKED = new Set(['image', 'media', 'font']);

const browser = await chromium.launch({
  proxy: {
    server: 'http://proxy.tierproxy.com:823',
    username: 'USERNAME',
    password: 'PASSWORD',
  },
});
const page = await browser.newPage();
await page.route('**/*', (route) =>
  BLOCKED.has(route.request().resourceType()) ? route.abort() : route.continue()
);
await page.goto('https://example.com/');
await browser.close();

Playwright: abort image, media and font requests, continue the rest.

Puppeteer does the same through request interception. Call page.setRequestInterception(true), then abort or continue each request from a request handler. Always call one or the other, because an intercepted request stalls until you do. A caveat: blocking stylesheets or scripts can break the page, and some sites may react to a browser that never asks for images. Try it on your 20 URLs before the big run.

How many GB to buy

GB never expires, so the right question isn't GB per month. It's GB per job. Work it out with your own numbers, round up, and buy that plus headroom. Leftover GB stay on the balance for the next job, so overbuying costs you only the cash tied up.

Orders run from 1 to 1,000 GB, which makes a one or two GB pilot cheap. Run the sample at real volume and compare the dashboard readout with your estimate. Within 10 percent, scale up. If the readout is much higher, the usual suspects are retries, redirects, and a client that isn't sending Accept-Encoding. The Residential tier is $1.20 per GB, and all four tiers are listed on the pricing page.

To pick between tiers, price the job on the per-job cost, not the per-GB price, and keep the retry factor in. If you're unsure your credentials and exit IP are right, how to test a proxy walks through it without spending much.

Frequently asked questions

How many pages can I scrape per GB?

It depends on what you download. At the Web Almanac 2025 median mobile page weight of 2,164 KB, about 462 full browser loads fit in 1 GB. A plain HTML document at 33 KB gives about 30,303. Measure your own target with curl before trusting either figure.

How much bandwidth does a headless browser use per page?

Roughly the page weight, which was a median of 2,164 KB on mobile in the Almanac's 2025 data, with one page in ten above 8,337 KB. Blocking images cuts a large share, since images are about 36 percent of the median mobile home page.

Do failed requests and redirects count against my GB?

In general, yes. Per-GB billing is based on traffic that passes through the gateway, and an error page or a redirect is still traffic. Confirm with your provider how headers and failed requests are counted, and put an attempts-per-page factor in your estimate.

Is 1 GB 1,000 MB or 1,024 MB?

By the SI prefixes a GB is 10^9 bytes, and 2^30 bytes is a GiB, per NIST. Vendors differ. The usage readout in our dashboard divides by 2^30, so reconcile a pilot against that readout instead of assuming.

How do I estimate proxy bandwidth for an API instead of web pages?

Fetch 20 sample endpoints with curl and add size_download, size_header and size_request for each. JSON endpoints skip images, scripts and fonts, so they're typically far smaller than the page around them, but we have no sourced average. Measure yours.

Sources

• HTTP Archive Web Almanac 2025: Page Weight
• MDN: Compression in HTTP
• MDN: Connection management in HTTP/1.x
• curl manual: write-out variables and --compressed
• Chrome DevTools: Network panel reference
• Playwright: Network, routing and proxy
• Puppeteer: Network interception
• RFC 9110: HTTP Semantics, 304 Not Modified
• NIST: Prefixes for binary multiples
• Wormly: TLS / SSL handshake size

Keep reading

• Residential vs datacenter proxies: how to choose
• Rotating vs sticky proxies: how proxy sessions work
• How to test a proxy: six checks, in order, with commands you can paste

See per-GB pricing

Explore TierProxy

• Residential proxies
• Buy IPv4 proxy
• Pricing
• Proxies by country
• Proxy checker
• What is my IP
• Blog