How Much Bandwidth Do You Actually Need? Port Speed, Not Volume, Is What Limits You

Bandwidth is the only line item on a hosting invoice that is sold by a word nobody can define. Capacity planning for it is usually done by looking at last month's transfer total, adding fifty percent, and picking whatever tier covers it — which is why so many teams discover their real limit only when a launch goes wrong. The number that stops you is not the one on the invoice. It is the port speed, and most buyers never look at it.

Here is the whole argument in one calculation. A 200 Mbps port can carry roughly 65 TB in a month if it runs at full rate continuously. A 5 TB monthly allowance on the same port is exhausted in about two days of saturation — after which you either pay overage or get throttled, regardless of how much headroom the tier promised. The allowance was never the constraint. The pipe was.

So the useful question is not "how much bandwidth do I need", because that phrasing invites a volume answer to a rate problem. It is "what is my peak rate, and is the port dedicated enough to hold it".

Every Bandwidth Plan Describes Two Numbers

Hosting plans conflate two independent specifications, and the conflation is deliberate enough to be worth naming.

Volume is the visible number because it is easy to compare. Port speed is the operative one because it determines whether the volume allowance is reachable at all, and how many users you can serve while spending it.

The relationship is arithmetic. A port speed in Mbps converts to megabytes per second by dividing by eight, and to a monthly ceiling by multiplying out the seconds:

Why the Page Weight Matters More Than the Visitor Count

To convert a port speed into a user capacity, you need the transfer size of one request. That figure has been measured continuously for years, and the current numbers are larger than most teams assume.

HTTP Archive's page weight report puts the median desktop page at roughly 2.9 MB and the median mobile page at roughly 2.6 MB as of September 2026. Images account for about 1 MB of that on desktop and 800 KB on mobile — the single largest component. The distribution has a long tail: the 90th percentile desktop page exceeds 12 MB.

Run the division. At 25 MB/s on a 200 Mbps port, and an average transfer of 2.6 MB per visit, you can serve roughly nine or ten visitors per second at full port utilisation. That is a perfectly healthy number for a business site and a catastrophic one for a page that streams video.

Which means the estimate that predicts your bill is not monthly sessions. It is average page weight multiplied by peak concurrent throughput, and the second half of that is a port-speed question.

What the Traffic Is Made Of Has Changed

Capacity estimates written before 2025 systematically under-provision, because a growing share of requests are not from people.

Cloudflare's measurement across its network put automated traffic past the majority threshold on 27 April 2026, and by early June the company reported 57.5% of HTTP requests were from bots rather than humans. AI crawlers alone accounted for roughly a fifth of verified bot traffic. The crawlers that matter are now a named list rather than one: GPTBot, ClaudeBot, PerplexityBot, CCBot, Google-Extended, Meta-ExternalAgent.

Three consequences follow for planning:

• Your transfer total overstates your human traffic. Log line counts are not visitor counts, and the gap is now large enough to distort a capacity estimate badly in either direction.
• Crawler volume scales with catalogue size, not popularity. A 5,000-page product catalogue gets walked regardless of whether anyone visits it, which is why a quiet site can still burn through an allowance.
• Standard analytics undercounts it. Most JS-based analytics never executes for a crawler, so the traffic that costs you money is the traffic your dashboard does not show.

The correction is cheap: read the raw access log, filter on user agent, and separate the two populations before estimating anything.

Unmetered, Unlimited, and Metered Are Three Different Contracts

The words are used interchangeably in marketing and describe genuinely different billing mechanics. Getting this wrong is the most common source of a bandwidth dispute.

• Metered — you are billed on actual transfer, with a base allowance and a per-TB overage beyond it. Transparent, and the only model where a traffic spike translates directly into a larger invoice. Some providers throttle instead of charging; confirm which applies to you.
• Unmetered — transfer is not measured or billed at all. Instead you pay a flat rate for a guaranteed port speed and may use it continuously without triggering overage. The ceiling is physical: a saturated 200 Mbps port cannot exceed ~65 TB no matter how the contract is worded.
• Unlimited — the least precise of the three, and in practice almost always one of the other two wearing a friendlier word. Either it is unmetered at a stated port speed, or it is a high metered allowance governed by a fair use policy.

True uncapped bandwidth at unlimited speed is not a product that exists, because every connection has a physical port. Which makes the only question that matters for any plan using the word: unlimited at what port speed, and is there a fair use policy? If either answer is unavailable in writing, treat the claim as unmetered-at-unspecified-speed, which is not a specification.

The Fair Use Policy Is the Operating System of "Unlimited"

An acceptable use or fair use clause sits in every flat-rate contract, and it — not the headline — defines what you actually bought. The clauses are rarely about transfer volume. They throttle the resources that a shared platform cannot oversell indefinitely.

This is also why a dedicated-CPU plan behaves differently from a shared one even when both advertise the same port speed: on shared infrastructure your practical throughput depends on what the other tenants are doing, because the physical interface is divided among them.

The Measurement Detail That Decides Your Bill

How transfer is measured matters as much as how much is allowed, and one method produces surprising invoices.

Under 95th percentile billing, the provider samples port utilisation every five minutes across the month, discards the highest 5% of samples, and bills the peak of what remains. Short bursts cost nothing, which is the point — but a sustained plateau becomes expensive, because discarding 5% of a month is only about 36 hours of relief. Two consecutive days of heavy traffic will not be discarded.

The alternative is straightforward total transfer, which is easier to predict but charges for every spike. Other models in use include inbound-free metering where only egress is billed, asymmetric regional pricing where local traffic is unmetered and international traffic is not, and unmetered-with-fair-use where the policy triggers somewhere between 5 and 20 TB.

Before comparing two quotes, establish which model each one uses. A "cheaper" allowance under 95th percentile billing can cost more than a larger allowance under simple metering, depending entirely on whether your traffic is bursty or sustained.

Estimating Your Own Requirement in Five Steps

This takes an afternoon and produces a number you can defend, which is more than most plans can say for theirs.

1. Measure peak concurrency, not monthly totals. Pull a week of access logs and find the busiest five-minute window. Average traffic never breaks a port; peaks do.
2. Calculate the peak rate. Multiply requests per second in that window by average response size in bytes. That product is your required port speed, in the same units your provider quotes.
3. Add growth and crawler allowance. Apply your expected growth rate, then add headroom for automated traffic — and verify the crawler share from your own logs rather than assuming a figure.
4. Choose the billing model that matches the shape, not the size. Bursty traffic suits unmetered at a modest port speed, or a metered allowance with generous overage terms. Sustained high throughput needs both a high port speed and either unmetered billing or interconnects that avoid per-TB charges.
5. Confirm the measurement method. Ask whether the figure is total transfer or 95th percentile, and whether inbound counts. The same traffic pattern can produce materially different bills under each.

Then sanity-check the result against the port ceiling from the table above. If your calculated requirement exceeds what the port can deliver, the allowance is irrelevant and you are buying the wrong plan regardless of price.

Where a High-Port-Speed Plan Earns Its Price

The workloads that benefit from a plan built around a high peak port speed rather than a large volume allowance share one characteristic: their traffic is intense, unpredictable, and bursty, and their cost is better modelled as flat capacity than as per-gigabyte consumption.

• Large file and data distribution. Mirrors, release artefacts, dataset downloads, backups. Transfer is large and the timing is not yours to control.
• Media delivery without a CDN. Serving audio, software installers, or video directly from origin, where the port speed is what determines how many simultaneous downloads complete acceptably.
• High-throughput peer-to-peer workloads. Traffic that runs continuously in both directions and would make metered billing unpredictable by design.
• Scheduled bulk operations. Nightly transfers, off-site replication, and synchronisation jobs that saturate the link for a bounded window.

For workloads like these, the deciding specification is the port speed and whether it is dedicated — a shared port at the same number will behave very differently at the moment it matters.

One current example is the ULightHost torrent-series plan on SurferCloud, deployed in the Los Angeles data centre at 200 Mbps unmetered with AMD EPYC processors and NVMe storage, priced from $5 per month for the entry configuration in earlier coverage of this plan. At a sustained 200 Mbps the port can move roughly 65 TB in a month, which is the practical figure to compare against any metered allowance you are currently buying.

Two characteristics of the plan are worth confirming against the estimate method above. The bandwidth is unmetered, so the port speed is the binding constraint rather than a transfer allowance. And the product is a lightweight cloud server, which means the resource ceiling is the plan configuration rather than dedicated hardware — for sustained CPU-heavy work alongside the transfer, the elastic compute range is the better fit.

The generic version of the advice applies regardless of which provider you choose: for distribution workloads, size the port and check that it is dedicated. For steady-state web traffic, size the allowance and stop paying for burst capacity you will never use. Those are two different purchases, frequently sold under the same plan name.

FAQ

Is unmetered bandwidth the same as unlimited bandwidth?
In most reputable contracts, yes — "unlimited" is usually a friendlier word for unmetered at a stated port speed. Always confirm the port speed and whether a fair use policy applies before assuming equivalence.

Can I be throttled on an unmetered plan?
Not for transfer volume, because there is no allowance to exceed. You can still hit CPU, process, and I/O limits under a fair use policy, which are separate ceilings.

How much traffic can a 200 Mbps port carry?
Approximately 25 MB/s, or roughly 65 TB in a month if run at full rate continuously. Real workloads almost never saturate a port for a full month.

What is 95th percentile billing?
The provider samples port utilisation every five minutes, discards the highest 5% of samples, and bills the remainder's peak. It forgives short bursts but not sustained traffic.

Does shared port speed matter if the number is the same?
Yes. A shared 200 Mbps port is divided among tenants, so your actual throughput at peak depends on what the others are doing. Dedicated means the number is yours.

How do I know my real bandwidth requirement?
Calculate it: peak requests per second multiplied by average response size. That gives a rate, which is what a port provides. Monthly totals alone will not tell you whether the port can carry them.

Summary

Bandwidth planning fails when it is framed as a volume question. Every plan states a transfer allowance and hides a port speed, and the port speed is what actually limits how many users you serve and how quickly. The allowance determines your bill; the port determines whether the service was ever capable of meeting the demand.

Three things are worth doing before the next purchase. Measure peak concurrency rather than monthly totals. Establish whether the quote is metered, unmetered, or unlimited-with-fair-use — and if it says unlimited, get the port speed in writing. Then check the measurement method, because total transfer and 95th percentile billing price the same traffic differently.

Do that and the tier selects itself: bursty distribution traffic wants a high dedicated port speed with unmetered transfer, while steady web traffic wants the smallest allowance that comfortably covers measured peaks. Most overpayments come from buying the second while needing the first, or the reverse.

To see the high-port-speed option described above, start with the 200 Mbps unmetered Los Angeles plan. If your requirement turned out to be sustained CPU rather than sustained transfer, the elastic compute range is the correct comparison, and the hourly plans let you measure real peak throughput before committing to a term.