Bandwidth Math for Static Hosts: Bytes, Requests and Build Minutes

“Unlimited bandwidth” is the most repeated claim in static hosting and the least precisely documented. When you go looking for the actual limit on a platform’s own limits page, you frequently find that no bandwidth figure exists at all — which is not the same as finding a generous one.

The reason is that the platforms meter different things. And once you see which meter each one uses, the comparison stops being about bandwidth and starts being about which resource your site consumes.

The formula, and what it is missing

The standard estimate for a content site:

monthly GB = average page weight (KB) × monthly pageviews ÷ 1,000,000

Worked examples, using typical page weights:

Site type	Page weight	50,000 pageviews/month	500,000 pageviews/month
Text-heavy, no images	~60 KB	~3 GB	~30 GB
Typical content site	~400 KB	~20 GB	~200 GB
Image-heavy	~1.5 MB	~75 GB	~750 GB

One caveat before you use these numbers: no platform publishes page-weight guidance to check them against. The formula is arithmetic, and the inputs are yours to measure. Open the site, look at the transfer size in DevTools, and use your own figure — a number you measured beats a number I estimated.

Three meters, not one

Here is the part that changes the decision. The platforms in this category do not meter the same quantity.

Platform	Bytes	Requests	Notes
Cloudflare Pages	Not documented as a meter	Only Functions requests count	Static asset bytes are not metered
Netlify	Yes — GB transferred	Yes — request count	Separate credit costs for each
Vercel	Yes — fast data transfer	Yes — edge requests	Plus image transformations, plus build CPU-minutes

Read the Cloudflare row carefully, because it is the outlier and the difference is not marketing. Pages’ documented limits page covers builds, custom domains, file count, file size, header rules, redirects and projects — and does not document a bandwidth cap, meter, or overage. The only request-type accounting on that page is that Functions requests count against Workers plan quotas. Static assets served from the edge are not in that count.

Netlify and Vercel, by contrast, meter bytes and requests as two separate line items with two separate allowances. That means a site that is tiny in bytes but generates a large number of requests — a page with hundreds of small icons, a site with an aggressive polling script, a site with many small API-ish fetches — can exhaust a request allowance while using almost no bandwidth.

Requests and bytes are different resources, and only one of them is what you were thinking about when you read “bandwidth.”

Why request count can matter more than bytes

Consider two sites, both serving 500,000 monthly pageviews:

• Site A: one 400 KB hero image per page. Bytes: ~200 GB. Requests: ~500,000.
• Site B: a page that loads 120 small icons, 8 fonts, and a handful of scripts. Bytes: ~90 GB. Requests: ~65 million.

Site A looks worse on bytes and is dramatically cheaper on requests. On a platform that meters requests, Site B is the expensive one — and nobody shopping for hosting would have predicted that from a feature table.

The mitigation is the same as always: reduce request count. Inline small assets, use a sprite or an icon font instead of 120 files, drop fonts you do not need. This is also the advice you would give for performance, which is a happy overlap.

The escape hatch nobody mentions in the pricing table

For genuinely large assets — video, big PDFs, downloadable datasets — Cloudflare documents a storage product with an explicit statement about egress: “There are no charges for egress bandwidth for any storage class.” Charges are for storage and for Class A and B operations.

That matters because it establishes that zero-egress pricing is a business choice available to a provider, not a cost floor. It also means “bandwidth is expensive” is not a law of nature, and a platform charging per gigabyte is charging for a meter it chose to install.

Build minutes are a third meter, and they are not bandwidth

Vercel’s publicly documented model bills builds per CPU-minute on top of transfer and requests. GitHub Actions, if you build in CI, meters its own minutes separately — and there the rule is precise: usage is free for public repositories on standard runners, while private repositories get a monthly allowance that differs by plan.

For a content site that rebuilds a few times a week, build minutes are a rounding error. For a site that rebuilds on every content change, or one with an expensive image pipeline, they are not. And note that a build meter is the one that scales with how much you publish, not with how many people read it — so a site with a large archive and a small audience is the worst case for it.

The comparison you should actually run

Build a table with your own numbers in it. Three columns per candidate platform:

Input	Where it comes from
Page weight, median	DevTools, your own site
Pageviews per month	Your analytics, or a forecast
Requests per pageview	DevTools network panel count
Monthly bytes	Formula above
Monthly requests	Pageviews × requests per pageview
Build frequency × duration	Your deploy log

Then check each against the platform’s documented allowance, and note which of the two meters is closer to its ceiling. The binding constraint is whichever one runs out first — and on a page with many small assets, it is rarely the one you assumed.

When this is all overthinking

• Your site is small. Under a few tens of thousands of pageviews a month, every platform here is comfortably within its free tier, and the decision should be made on other grounds — deploy workflow, build times, redirect support.
• Your bytes are the constraint and they are large. Video and large downloads are the case where egress pricing genuinely decides the platform. Look for documented zero-egress options and price accordingly.
• Your requests are the constraint. Reduce request count before changing platforms. It is free, it improves the visitor’s experience, and it moves the meter you were about to pay to raise.

The headline claim is true on all three platforms in the sense that matters: none of them will send you a surprise invoice for serving more pages. What they will do is meter whichever resource you forgot to count.