How Much Proxy Data Do I Need? Real Numbers

One gigabyte of residential proxy traffic buys roughly 3,000 to 20,000 pages if you fetch the HTML and let it compress, or about 350 pages if you load them in a real browser with images, scripts and fonts. The spread is that wide because the bandwidth a page costs depends on what you fetch, not on the site. Below is what we measured on 11 major pages, the formula that turns a monthly page count into gigabytes, and the settings that move you from the expensive end of the range to the cheap one.

What actually counts as a gigabyte

Proxy providers meter bytes on the wire, in both directions, including headers and TLS overhead, and the body they count is the compressed one the server sent. That distinction matters more than anything else on this page. A modern HTML page is served gzip- or brotli-compressed, and text compresses well: in our measurement the decoded HTML was 4.7 to 10 times larger than what crossed the wire. Two consequences follow. A tool that reports “page size” after decoding overstates your proxy usage several times over. And a client that forgets to send Accept-Encoding: gzip, br pays the decoded size for real.

The other large multiplier is rendering. A plain HTTP fetch downloads one document. A headless browser downloads the document plus every script, stylesheet, font, image and tracking pixel the page references. The HTTP Archive's 2025 Web Almanac puts the median total page weight at 2,862 KB on desktop and 2,559 KB on mobile, against an HTML document that is usually the smallest part. Rendering the same page costs 10 to 50 times the bandwidth of fetching it.

What we measured: 11 major pages, 3 September 2026

We fetched one representative page from each site with a plain HTTP client, a Chrome TLS profile and US residential exits, and recorded the decoded HTML size. Where the server sent a Content-Length header we also have the exact compressed size on the wire; the others were streamed in chunks, so the wire size is estimated from the measured compression ratios.

Two clusters. Content and reference pages cost 47 to 63 KB on the wire and give you 16,000 to 21,000 pages per gigabyte. Commerce, travel and job search pages, which inline product data and scripts into the HTML, cost 280 to 370 KB and give you about 3,000. The difference is not the proxy; it is the page. Five other sites in the same run refused the plain fetch outright, which is a different problem covered in the 403 guide, and one worth remembering here: a refusal costs almost nothing in bandwidth, but if it forces you into a browser, the cost per page rises by an order of magnitude.

The formula

GB per month  =  pages per month  ×  bytes per page on the wire  ×  1.1   ÷  1,000,000,000

# the 1.1 covers request headers, TLS handshakes, redirects and retries; use 1.3 if you retry aggressively

Three worked examples with the numbers above:

• 100,000 product search pages a month, HTML only: 100,000 × 350 KB × 1.1 = 38.5 GB. At $0.80/GB on Residential Basic that is about $31.
• 100,000 article pages a month, HTML only: 100,000 × 55 KB × 1.1 = 6 GB, under $5.
• 100,000 product pages rendered in a headless browser: 100,000 × 2,800 KB × 1.1 = 308 GB, about $246. Same pages, eight times the cost of the HTML fetch.

The lesson is in the third line. Before sizing a plan, decide how many of your pages truly need JavaScript. A page whose data is in the HTML, or in a JSON blob embedded in it, should never be rendered for bandwidth reasons alone.

How to cut usage by 5 to 20 times

1. Send Accept-Encoding: gzip, deflate, br. Most clients do by default; some minimal ones do not. This alone is a 4 to 10 times difference, and brotli is typically 15 to 25 percent smaller than gzip on HTML.
2. Do not render unless the data is not in the HTML. Fetch once with a plain client and look for the data or for an embedded state object (__NEXT_DATA__, window.__INITIAL_STATE__, JSON in a script tag). The scraping API has an app_state option that mines exactly those blobs, and an engine: tls setting that refuses to escalate to a browser, so you can measure what the cheap tier gets you.
3. If you must render, block what you do not need. Route images, fonts, media and third-party analytics to abort in Playwright or Puppeteer. Scripts and stylesheets usually have to load; images rarely do. This typically cuts a render from 2.8 MB to 400 to 800 KB.
4. Prefer the site's own JSON endpoints. Search pages often call an internal API that returns 20 to 80 KB of JSON for the same results the HTML carries in 350 KB. Recording XHR traffic once and then calling the endpoint directly is the single largest saving on commerce sites.
5. Use conditional requests for monitoring. If-None-Match with the last ETag returns a 304 with no body when nothing changed. For price monitoring on pages that change daily, that is a 95 percent reduction.
6. Cap the body. Stop reading after the section you need, or after a byte limit. Infinite-scroll pages and long comment threads are where a “page” quietly becomes 5 MB.
7. Match the IP type to the target. Static and low-security sites do not need residential bandwidth; datacenter exits at $0.50/GB and IPv6 at $0.083/GB at volume exist for that. Spend residential gigabytes only where the target checks.

When per-page pricing beats per-gigabyte

Per-GB billing and per-page billing cross over at a page weight you can compute. The scraping API charges $0.0002 per successful plain fetch regardless of size; $0.80 of residential bandwidth buys 4,000 such fetches, so the break-even is 1 GB ÷ 4,000 = 250 KB on the wire. Lighter than that, raw proxies are cheaper; heavier, the per-page API is. On our table that puts articles, Wikipedia, GitHub and Reddit on the proxy side and Amazon, Walmart, Indeed and the NYTimes front page on the API side. Rendered pages are not close: $0.001 per rendered page against 2.8 MB of bandwidth at $0.80/GB, which is $0.0022, before counting the failed renders that the API does not bill and a proxy does.

The comparison assumes every request succeeds. If a share of your fetches are blocked and retried, the per-GB cost rises with the retries, while the per-page cost does not move. The proxy side of the math is also where the residential proxy guide goes into rotating versus sticky sessions; the bandwidth is the same either way, but sticky sessions avoid paying a new TLS handshake per request, which is a few KB each time.

Sizing by volume is only half the question

Gigabytes answer “how much”. They do not answer “how fast”. If you need 1,000 pages a minute against a site that tolerates 10 requests a minute per IP, you need 100 exits in flight regardless of whether the month costs 6 GB or 300 GB, and that is a concurrency question answered in the 429 guide. A rotating gateway decouples the two: bandwidth is what you buy, concurrency is how many connections you open, and the pool handles IP variety underneath. Size the gigabytes from the formula, size the concurrency from the target's tolerance, and revisit both after the first week of real traffic, which will tell you your actual bytes per page better than any table, including this one.