Where your gigabytes actually go

If you are billed per gigabyte, it is worth knowing what you are actually buying. Most people picture the data they came for — the price, the listing, the search result. That is almost never where the bytes go.

The median web page is about 2.6 MB on desktop and 2.3 MB on mobile. The piece you wanted is usually a rounding error inside that.

One page, by weight

Here is a typical 2.6 MB page, drawn to scale. The HTML — the part that contains the text and the numbers you are extracting — is the thin sliver on the left.

Images are consistently the heaviest resource type, with JavaScript second. Third-party content — advertising, analytics, tag managers, tracking pixels — commonly accounts for 30 to 50 percent of the total.

Read that again in billing terms. On a metered plan, somewhere between a third and a half of your spend can go to downloading other companies’ advertising infrastructure, on pages where you only ever wanted the text.

Why this happens quietly

If you fetch with a plain HTTP client, none of this applies. You request the HTML, you get the HTML, you pay for 60 KB.

The moment you drive a real browser, the browser does what browsers do: it fetches everything the page references. Every image, every font, every analytics beacon, every ad exchange call. Headless Chrome is not more frugal than the one on your desktop — it is the same engine with the window switched off.

That is why teams migrating from requests to Playwright often see their bandwidth bill jump by a factor of twenty for identical output. Nothing broke. The browser simply started paying for the whole page.

What blocking actually saves

The good news is that most of that weight is optional for your purposes, and browsers make it straightforward to refuse.

Blocking images, media, fonts and third-party domains typically removes 40 to 70 percent of page weight while leaving the DOM you are reading entirely intact. Prices, stock levels, titles and review text all live in the HTML and the first-party scripts. They do not live in the ad exchange call.

There are pages where this breaks things — sites that lazy-load content behind an image observer, or that gate rendering on a third-party script. You will find those quickly, and you can allow-list per domain. The default should be to block.

The thirty-second test

Before changing anything, find out what one page actually costs you. Load a target with a plain client and then with your real pipeline, and compare:

curl -so /dev/null -w "html only: %{size_download} bytes\n" https://example.com/

That is your floor — the bytes containing the data. Then check what your browser-based run transfers for the same URL, from your own metering or the browser’s network panel. The ratio between those two numbers is what resource blocking is worth to you, expressed in money.

If the gap is twenty-fold, and on media-heavy retail pages it often is, the afternoon spent adding a request interceptor pays for itself in days.

Making it stick

Three habits keep the bill honest.

Block by resource type first. Images, media, fonts and stylesheets are the fastest win and almost never affect extraction.

Then block by domain. Analytics and ad domains are the second tranche, and they are the ones most likely to fail slowly and drag your timings out as well as your bytes.

Measure per target, not globally. Page weight varies enormously by sector. A retail listing and a plain JSON endpoint are not remotely the same purchase, and your average across both tells you nothing useful.

None of this is exotic. It is just the difference between paying for the data you asked for and paying for everyone else’s advertising. If you are weighing metered against fixed pricing in the first place, per GB, per port, or unlimited works through the break-even, and how proxy bandwidth is measured explains why your own counter and any provider’s meter will never quite agree.