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 9 to 233 KB, and rendering the same pages cost 47 KB to 3.6 MB. Up to fifty-eight times more, for identical work.

What we measured

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

Page	Document	Fully rendered	Requests	Multiplier
news.ycombinator.com	34 KB	47 KB	7	1.4x
Wikipedia article	46 KB	414 KB	36	9x
books.toscrape.com product	9 KB	525 KB	11	58x
webshare.io pricing	233 KB	4,923 KB	75	21x
bbc.com/news	69 KB	3,594 KB	102	52x

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:

How you fetch, 250,000 pages	Data	At $2.50/GB	At $0.42/GB
Document only, light pages	8.5 GB	$21	$4
Document only, typical	12.5 GB	$31	$5
Rendered, light	104 GB	$259	$43
Rendered, retail product pages	131 GB	$328	$55
Rendered, heavy news	899 GB	$2,246	$377

The range is 106x, and the provider is not what moved it. The two rate columns are the cheapest and a mid-market rate from the plans we track, and the difference between them is small next to the difference between the rows.

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.

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.