The question that got me to sit down and do this math was a bill. A pay-per-GB job I'd budgeted at "maybe a few dollars" came in at forty-something, and I genuinely didn't understand why until I looked at what each request was actually dragging down the wire.

Here's the short version: you're almost never paying for the HTML. You're paying for everything that loads with it.

The napkin math

Bandwidth for a scraping job is basically:

requests × average transfer per request × overhead

The first number you know. The second one is where people guess badly. And the overhead — retries, redirects, failed requests you still paid for — quietly adds 10–20% on top.

The trap is assuming "a page" means the HTML. A product page's HTML might be 50–150 KB. But if you load it in a real browser, you also pull CSS, JavaScript bundles, fonts, tracking scripts, and a pile of images — and suddenly one "page" is 2–5 MB. That's a 20–40x difference from the raw HTML, and it's the single biggest factor in your bill.

So the same 100,000-page job can cost wildly different amounts:

• Raw HTTP, HTML only (~100 KB/page): ~10 GB
• HTTP with assets you actually need (~600 KB/page): ~60 GB
• Full headless browser, nothing blocked (~3 MB/page): ~300 GB

Same job. Same page count. A 30x spread, entirely down to how you fetch.

Put real numbers in

Rather than eyeball it, drop your figures into the data & cost calculator — request count, average page size, an overhead percentage and your price per GB — and it gives you the total transfer and the cost, including a cost-per-1,000-requests number that makes it easy to compare approaches. Change the average page size from 3 MB to 600 KB and watch the total drop; that one slider is most of your bill.

Where the savings actually are

• Block assets you don't need. In Playwright or Puppeteer, abort image, font, media and stylesheet requests unless you specifically need them rendered. For most data extraction you don't. This alone often cuts browser traffic by more than half.
• Skip the browser when you can. If the data is in the HTML or a JSON endpoint, a plain HTTP client (requests, httpx) transfers a fraction of what a headless browser does. Reserve the browser for pages that genuinely need JavaScript execution.
• Reuse sessions. Re-handshaking TLS and re-downloading the same boilerplate on every request adds up across hundreds of thousands of calls.
• Cache the obvious. If you hit the same category pages repeatedly, don't re-download them every run.
• Fail fast. A tight timeout and a sane retry policy stops you paying for dead requests three times each.

Why this matters more on mobile proxies

Mobile and residential proxies are billed per GB, not per IP, so your cost scales with download volume — which means the asset-blocking stuff above isn't a nice-to-have, it's your main cost lever. It's also worth checking whether your GB expire. A lot of providers reset your balance monthly whether you used it or not; VeilSocks doesn't expire unused data, which matters a lot for bursty jobs that sit idle and then spike.

Estimate first, block what you don't need, and keep the browser for when you actually need it. Do those three things and the scary bill mostly goes away.