Work out your bandwidth before you compare a single price

Multiply your requests by your average page weight. That average is the number almost everyone guesses, and it is worth measuring: on five real pages, fetching the document cost 5 to 66 KB on the wire, and rendering the same pages cost 47 KB to 3.6 MB. Up to a hundred and eighty times more, for identical work.

Measuring five real pages

Five pages, loaded through a real browser on 15 August 2026, recording the document size and the total bytes transferred:

Correction, 27 August 2026: the Document column mixes two bases and two of its rows understate the gap. A proxy bills what crosses the wire, which is gzip or brotli. Re-fetching all five, once with Accept-Encoding: identity and once compressed, shows which figure each row actually carried:

                              in the table    raw    wire
news.ycombinator.com                  34 KB   34 KB     5 KB   <- raw
en.wikipedia.org (article)            46 KB  235 KB    46 KB   <- wire
books.toscrape.com (product)           9 KB    9 KB     9 KB   <- served uncompressed
www.webshare.io/pricing              233 KB  233 KB    27 KB   <- raw
www.bbc.com/news                      69 KB  400 KB    66 KB   <- wire

The rendered column comes from a browser, which reports the compressed transfer, so the Wikipedia and BBC multipliers are right. Hacker News and Webshare are not: their document figure is the uncompressed file, so the true gap on those rows is roughly 9x and 180x rather than the 1.4x and 21x printed. The argument this post makes gets stronger, not weaker, and the numbers it made it with were inconsistent.

The rendered column has not been re-measured, so the table is left as published rather than half-corrected into a third basis.

Hacker News is the control: almost no assets, so rendering it costs barely more than fetching it. Everything else carries images, fonts, stylesheets and scripts that your parser will never look at and your proxy will bill you for.

The bookshop page is the one to sit with. Nine kilobytes of HTML, half a megabyte on the wire. It is a small product page on a site built for scraping practice, and rendering it costs fifty-eight times what reading it costs.

The arithmetic, at a quarter of a million pages

Take the same job and change nothing except how you fetch:

The range is 106x, and the provider is not what moved it. Both columns are residential, so they compare like with like: $2.45 is the median of the 190 residential plans we hold a rate for, and $0.27 is the cheapest of them, which is Geonode's 100 TB rung. The gap between the columns is roughly 9x. The gap between the top and bottom rows is 106x.

Cheaper rates exist and they are not residential. The lowest rate in the whole catalogue is $0.144/GB, also Geonode, on datacenter at 100 TB, and a datacenter address is a different product that a careful site will block. Comparing a datacenter floor against a residential median would flatter the wrong number.

So the order of operations matters. Work out which row you are on, then compare prices, because volume decides which tier you can buy at and the rate you compared may not be the rate you end up paying.

Three things that quietly multiply the number

Rendering you did not need. If you launch a headless browser because one page in twenty needs JavaScript, you are paying render costs on the other nineteen. Fetch first and escalate only on failure.

Assets you never parse. Every browser automation tool can block image, font, media and stylesheet requests. On the BBC page that is the difference between 3,594 KB and something close to the 69 KB document. This is the single biggest lever on the list and it usually costs four lines of configuration.

Failures. A challenge page, a 403 and a redirect all transfer bytes and all bill. If a target blocks a third of your attempts, your real cost is your success budget plus the retries, and a hard target can quietly double the total.

How to get your own number in ten minutes

1. Take a sample of 20 to 50 URLs that look like the ones you will actually fetch. Not the homepage, the pages with the data on them.
2. Run them the way you intend to run the job, with the same rendering and blocking settings.
3. Read the bytes off the proxy, not off the parser. Provider dashboards report what you were billed. Your own code reports what it kept, and the two are different numbers.
4. Multiply by your monthly request count, then add your failure rate. If you have no sample to measure yet, the bandwidth estimator will do the same arithmetic from our own page-weight measurements.

Then take that figure to the cost calculator, which prices it against every metered plan we track, and the number you get back is one you can hold a provider to.

One more decision sits underneath this. If your pages turn out to be small and your volume high, the per-request model may beat the per-gigabyte one entirely, and that crossover is its own piece of arithmetic. If you want the current rates for residential proxies to run your own numbers against, they are on the table with the date each one was read.