Bandwidth estimator

What this tool does

It estimates the monthly data transfer a site needs, from three inputs you can get in a few minutes: how many visits you get, how many pages each visitor views, and how heavy an average page is.

The arithmetic is straightforward — visits × pages per visit × page weight — with one adjustment. Repeat visitors already hold most of your static files in their browser cache, so their page views cost far less to serve than a first visit. The estimate assumes roughly 70% of a typical page is cacheable, and discounts returning traffic accordingly.

The final figure adds 30% headroom, because real traffic is lumpier than an average suggests and because bots, crawlers and monitoring all consume transfer that never shows in your analytics.

Where to get the three numbers

Monthly visits comes from your analytics. Use sessions or users — either is close enough for this purpose.

Pages per visit is also in analytics, usually as pages per session. Two to three is typical for a content site; one to two for a landing page; more for documentation or a store with browsing behaviour.

Average page weight is the one people guess at, and it is the input that matters most. Open your site in a browser, open the network panel in developer tools, do a hard refresh, and read the total transferred. Do this for two or three page types — a homepage, an article, a product page — because they often differ substantially.

If you cannot measure it, any page speed testing tool reports total page weight. Anything over 2MB is worth investigating regardless of bandwidth.

Why your host will usually see less than this

The estimate describes what gets delivered to visitors. What your origin server serves can be considerably less, for two reasons.

A CDN absorbs most static delivery. Once images, CSS, JavaScript and fonts are cached at edge locations, your server only handles the HTML and cache misses. For an image-heavy site that can remove the large majority of transfer from your hosting allowance. This is the single biggest reason estimates overshoot.

Compression is applied in transit. Text assets are served with gzip or Brotli, typically 60–80% smaller than the raw file. Most measurement tools already report the compressed size, so this is usually accounted for — but if you are working from raw file sizes on disk, you are overestimating substantially.

The practical implication: use the estimate to check whether a plan's allowance is in the right order of magnitude, not to predict your bill to the gigabyte.

Reading "unlimited bandwidth"

Very few hosting plans are genuinely unmetered, and the ones that advertise it are almost always subject to a fair use policy buried in the terms of service.

What to look for instead of the word "unlimited":

The actual allowance in TB. If the plan states one, that is the number that matters.

What happens on overage. Three common outcomes: you are charged per additional GB, you are throttled to a slower speed, or the account is suspended pending an upgrade conversation. The first is predictable, the second degrades the site quietly, the third is the one that ruins a day.

The overage rate. Per-GB pricing varies enormously between providers. Where a plan is otherwise attractive, this number decides whether a traffic spike is an inconvenience or an expensive mistake.

Port speed. Separate from allowance, and it caps how fast you can serve at peak. 1Gbps is standard; 100Mbps will bottleneck large file transfers and backups regardless of how much monthly transfer you are allowed.

Whether inbound counts. Usually it does not, but for anything accepting large uploads it is worth confirming.

When bandwidth actually becomes the constraint

For most websites, it does not. A content site doing 50,000 monthly visits at 1.5MB a page uses well under 100GB — comfortably inside almost every plan sold.

Bandwidth becomes a real consideration in four situations:

Video or audio served from your own origin. A single 100MB video watched a thousand times is 100GB on its own. This is why video hosting is a separate service; serving it yourself is rarely the cheaper option once transfer is counted.

Large downloads. Software, PDFs, high-resolution assets, datasets.

Unoptimised images at scale. A site averaging 6MB a page uses four times the transfer of one averaging 1.5MB, for identical traffic. Optimising images is cheaper than upgrading the plan, and improves conversion at the same time.

Bot traffic. Aggressive crawlers, scrapers and monitoring can account for a meaningful share of transfer on a site with a large URL space. If your measured usage is far above this estimate, check your server logs before assuming the estimate is wrong — it is frequently bots.

Reducing what you serve

In rough order of effect:

1. Convert images to WebP or AVIF and size them correctly. Usually the largest single saving available, often halving page weight on an unoptimised site.
2. Put a CDN in front. Free tiers cover static asset caching and cut origin transfer sharply.
3. Enable Brotli compression for text assets — around 15% better than gzip.
4. Set long cache headers on versioned static files, so returning visitors refetch less.
5. Lazy-load below-the-fold images, so visitors who never scroll never download them. Keep the hero image eager.
6. Move video to a dedicated video host rather than serving it yourself.

A worked example

A content site with 25,000 monthly visits, 2.4 pages per visit, 1.8MB average page weight, and 60% returning traffic:

• 60,000 page views
• At 1.8MB that is 108GB raw
• Discounting cached repeat views brings it to roughly 61GB
• With 30% headroom, plan for about 80GB

Every mainstream hosting plan covers that comfortably, so bandwidth is not a factor in the decision — which is itself useful to know before paying for a plan chosen on transfer allowance.

Now change one input: raise page weight to 5MB because the images were never optimised. The same traffic needs roughly 220GB. Same visitors, same content, nearly three times the transfer — and a slower site.