Hosting Traffic and Bandwidth: Calculation Reference

For shared hosting or a VPS, calculate transfer volume and transfer rate separately. Monthly GB describes how much data moves during a period; Mbps describes how quickly it moves within a chosen interval. This reference covers page loads, active simultaneous downloads, video, APIs and CDN byte hits, with explicit units and measurement boundaries.

Use the formulas below as calculation references. The numerical inputs are hypothetical checks, not measured customer traffic or forecasts. For a reusable input table and worked monthly-average versus busy-hour cases, continue with the monthly traffic and busy-hour examples.

Choose the Quantity Before Choosing the Formula

A correct equation answers only the question defined by its units and observation window. Keep these purposes separate:

• Transfer allowance: Compare GB/TB for the accounting period and the directions charged.
• Network capacity: Compare demand within a stated interval with usable throughput, sharing terms and any guarantee.
• Other resources: CPU, memory and storage can constrain the application independently of network usage.
• Cost: Oversizing increases spending on capacity you may not use; no fixed price multiplier follows from the arithmetic.

We’ve already shared a broader capacity planning framework in our detailed guide on how much CPU, RAM and bandwidth a new website needs. Here we’ll zoom in specifically on traffic and bandwidth: how to estimate them, convert between “GB per month” and “Mbps”, and map those numbers to shared hosting versus VPS in a practical way.

Key Concepts: Traffic, Bandwidth, Data Transfer and Concurrency

Hosting terminology can be confusing because several words are used interchangeably. Let’s clarify the terms we’ll use:

Traffic vs. Data Transfer

• Traffic (visits, pageviews): Visitor activity recorded as sessions and page-view events in tools such as Google Analytics or Matomo. Users, sessions and pageviews are distinct counts; one user can start several sessions.
• Data transfer (GB/month): For this estimate, the data sent from your server to visitors over a period, usually a month. Hosting plans often describe a transfer allowance as “monthly traffic” or “bandwidth included”; check whether the allowance counts outbound data only or both directions.

Here, traffic means visits and pageviews; each pageview can generate multiple requests. Data transfer is the total bytes transferred by those requests.

Bandwidth (Mbps)

Bandwidth is the maximum rate at which data can be transferred at a given moment, usually measured in megabits per second (Mbps). Think of it as the width of your pipe. Two sites can both use 1 TB per month, but if one gets all its traffic in a few hours each day, it needs more bandwidth than a site where traffic is evenly spread 24/7.

Hosting providers sometimes state bandwidth as:

• Port speed (e.g. 100 Mbps, 1 Gbps on a VPS or dedicated server)
• “Unmetered” transfer on shared hosting, which describes metering rather than a guaranteed Mbps rate. Fair-use terms may still apply, and separate CPU/IO limits can constrain site performance.

Concurrency (Simultaneous Users)

Active transfer concurrency counts transfers that overlap in time, not everyone with an open visitor session. On a hypothetical 1 Mbps bottleneck, ten simultaneous 1 MB downloads require 10 MB × 8 ÷ 1 Mbps = 80 seconds of aggregate link service, ignoring overhead and all other traffic. Per-user throughput need not be divided equally.

For bandwidth planning, count overlapping transfers rather than all open visitor sessions. An illustrative assumption such as “peak = 5x average hourly traffic” estimates a traffic rate, not concurrency; concurrency also depends on how long each transfer lasts.

Reference 1: Pageviews to Monthly Transfer

Let’s build a practical estimation process you can reuse for any project. You’ll only need:

• Sessions and pageviews for the same period
• Transferred MB per page, weighted by page type and cache state
• Additional traffic not included in those page measurements
• An explicit growth or uncertainty allowance

1. Estimate Monthly Visitors and Pageviews

If your site is already live, use analytics:

• Monthly sessions (visits)
• Monthly pageviews

If you’re planning a new site, build low, expected and high traffic scenarios based on your audience and marketing plans. The following are illustrative planning inputs, not forecasts or benchmarks:

• New blog: 3,000–10,000 pageviews/month in the first few months
• Local business site: 1,000–5,000 pageviews/month
• Growing e‑commerce: 20,000–100,000 pageviews/month depending on marketing

If you expect aggressive marketing or big campaigns, keep that in mind now; we’ll add a safety margin later. For more campaign-oriented planning, you can also refer to our hosting scaling checklist for traffic spikes and big campaigns.

2. Measure Average Page Size

For transfer planning, use the bytes actually transferred for HTML, CSS, JS, images, fonts, and other assets per page load, rather than their uncompressed resource sizes.

To measure it:

1. Open your site in Chrome or Firefox.
2. Open Developer Tools → Network tab.
3. Load a representative page (home, article, product page) with the browser cache disabled for a first-visit estimate, then repeat with caching enabled to assess repeat visits.
4. Look at the transferred bytes in the Network summary, not the uncompressed resource total.

Measure representative pages and weight the average by expected pageviews and first versus repeat visits. Separate third-party and CDN-served assets from hosting-origin transfer: browser totals are not the hosting provider’s meter. The following ranges are illustrative inputs, not measured sector averages:

• Well‑optimized blog page: 0.5–1.5 MB
• Image‑heavy article or portfolio: 2–5 MB
• Unoptimized pages with large images: easily 5–10+ MB

If you’re still in development, you can estimate based on your design and content strategy. Compression (gzip/Brotli) and suitable image formats (WebP/AVIF) can reduce transferred bytes. A CDN can reduce origin transfer by serving cached assets, but does not inherently make those assets smaller. We explain this in depth for image‑heavy sites in our hosting strategy guide for image-heavy websites using WebP/AVIF and CDN.

3. Calculate Monthly Data Transfer

Now we combine pageviews and average transferred page size to estimate page-load traffic. This is a baseline, not total account usage: downloads, bots, API traffic and other transfers need separate allowances.

Formula:

Monthly data transfer (MB) = Monthly pageviews × Average page size (MB)

Then convert MB → GB:

GB = MB ÷ 1000 uses decimal units. Binary units use GiB = MiB ÷ 1024. Specifically, 1 MB = 1,000,000 bytes and 1 MiB = 1,048,576 bytes; 1 Mbps = 1,000,000 bits per second. Check the source unit before converting, rather than changing only the label.

Example 1: Small Blog

• Pageviews: 10,000/month
• Average page size: 1.5 MB

Data transfer:

• 10,000 × 1.5 MB = 15,000 MB ≈ 15 GB/month

Example 2: Image-Heavy Portfolio

• Pageviews: 20,000/month
• Average page size: 4 MB

Data transfer:

• 20,000 × 4 MB = 80,000 MB ≈ 80 GB/month

Example 3: Growing E‑Commerce

• Pageviews: 100,000/month
• Average page size: 2.5 MB

Data transfer:

• 100,000 × 2.5 MB = 250,000 MB ≈ 250 GB/month

Monthly transfer alone does not determine whether shared hosting or a VPS is suitable. Compare these estimates with the plan’s transfer allowance and network limits, then assess peak demand and CPU, RAM and IO needs. Hundreds of GB or TB-level usage warrants checking those limits, but is not by itself a reason to move to a VPS.

Reference 2: Monthly Volume to Average Mbps

This conversion yields the average over the entire selected period. It does not reveal the busy-hour average, the maximum over shorter intervals or active transfer concurrency. Obtain those separately from measurements or explicitly stated scenarios.

First, convert monthly GB to average Mbps:

1. Convert decimal GB to MB: GB × 1000.
2. Convert MB to megabits: MB × 8.
3. Divide by the period in seconds. Exactly 30 days × 24 × 3600 = 2,592,000 seconds; calendar months can differ.

Formula:

Average Mbps ≈ (GB × 1000 × 8) ÷ 2,592,000

Example: 250 GB per Month

• GB = 250
• MB = 250 × 1000 = 250,000 MB
• Megabits = 250,000 × 8 = 2,000,000 Mb
• Average Mbps = 2,000,000 ÷ 2,592,000 ≈ 0.77 Mbps

So on average, 250 GB/month is less than 1 Mbps. But traffic is not flat; you’ll have busy hours.

Multipliers can illustrate sensitivity, but cannot recover a missing traffic distribution:

• Assume peak bandwidth ≈ 3–5 × average for this example; actual peaks may be much higher.

Using the unrounded 250 GB result, a hypothetical 3–5× rate would be approximately 2.315–3.858 Mbps. This is multiplication of an assumption, not a measured peak or a sufficient port target. Use busy-period data and active transfer requirements to select capacity.

Allow for Uncounted Traffic and Growth

Record which bytes are already included before adding traffic or growth. A buffer is a planning assumption; it is not a measured usage value or a guarantee against bursts.

• Protocol overhead: TCP/IP, TLS, headers, and retries add traffic, but the percentage varies. Account for what your measurement and provider’s transfer meter already include.
• Bot traffic: Crawlers and bots add requests that visitor analytics may not capture; include both useful crawlers and unwanted traffic.
• Cache misses: Browser cache hits can avoid repeat downloads, and CDN cache hits can avoid origin transfers. Server-side page caching alone does not eliminate the bytes sent to visitors.
• Growth: Base growth allowances on your forecast. For example, model 20–50% growth over the next 6–12 months as a scenario, not a prediction.

A simple way to account for this:

• For illustration, multiply the monthly GB estimate by 1.5× (a combined 50% allowance for uncounted traffic and growth).
• Use 5× average as the illustrative peak assumption here; replace it with measured busy-period demand or a campaign-specific estimate when available.

Revisiting our 250 GB e‑commerce example:

• Adjusted monthly transfer: 250 GB × 1.5 = 375 GB/month.
• Average Mbps = (375 × 1000 × 8) ÷ 2,592,000 ≈ 1.157 Mbps for the same 30-day period.
• A hypothetical 5× rate is about 5.787 Mbps. It remains an assumed multiplier, not peak evidence.

Compare the monthly transfer allowance and fair-use terms separately from the required peak Mbps. A VPS port advertised at 100 Mbps, 250 Mbps or 1 Gbps does not by itself establish guaranteed throughput or the included monthly transfer.

Shared Hosting vs VPS: How Limits Are Actually Applied

Now that you have numbers, how do they map to real-world hosting plans?

Shared Hosting: Limits Beyond Monthly Transfer

Shared hosting plans may impose network or transfer limits as well as resource limits such as:

• CPU limits (check how the plan defines the available CPU allocation)
• Memory (RAM) limits
• Disk IO / IO operations
• Entry-process limits and any separate PHP worker limits

Many shared plans advertise “unmetered” or very high transfer allowances, but CPU or IO limits can still cause throttling or rejected requests even when monthly transfer is within the plan’s terms. To understand these limits better, you can read our guide to cPanel resource limits and fixing the ‘Resource Limit Reached’ error.

For example, consider a small to medium site with these characteristics:

• Serve optimized pages (under 2–3 MB on average)
• Use caching plugins (for WordPress) and basic image optimization
• Stay below ~100–150 GB/month in real traffic

Shared hosting may suit this example if measured peak demand fits the plan’s limits; 100–150 GB/month is not a universal cutoff. Heavy dynamic workloads (e.g. badly cached WordPress or high cart activity) can exhaust CPU or other resources even at low monthly transfer.

When a VPS Becomes the Better Fit

A VPS makes sense when one or more of these apply:

• You regularly exceed shared hosting CPU/IO limits even with optimization.
• Your monthly transfer is in the high hundreds of GB or multiple TB and exceeds your shared plan’s allowance or fair-use terms.
• You need more network capacity for downloads, APIs or streaming. Compare port rates (e.g. 100 Mbps or 1 Gbps), sharing policies and any explicit throughput guarantees; a VPS does not automatically provide guaranteed bandwidth.
• You require custom server software, advanced caching (Redis, Varnish) or database tuning.

Starting with shared hosting for smaller sites and considering a VPS once performance or flexibility needs outgrow the shared environment is one possible upgrade path. Plan the migration separately from capacity sizing; our article on moving from shared hosting to a VPS with zero downtime provides a migration checklist.

Reference 3: Downloads, Video and API Responses

So far we’ve focused on “normal” web pages. Some workloads change the picture significantly.

1. File Downloads (PDFs, Installers, Assets)

If you host downloadable files, monthly data transfer depends on:

• Average file size (e.g. 10 MB PDF, 200 MB installer)
• Number of downloads/month

Formula:

Download data (GB) = (File size in MB × Number of downloads) ÷ 1000

Add this to your pageview‑based estimate only if those download bytes are not already included. Peak Mbps also depends on simultaneous downloads and the target speed per download. Even “small” downloads add up quickly if they’re popular. For heavy download sites, compare a VPS with adequate network capacity against object storage + CDN, including transfer costs and limits. Our guide on object storage vs block storage vs file storage for web apps and backups is a good next step if you’re considering that approach.

2. Images and Video

Large images and self‑hosted video can dominate your bandwidth usage. To keep costs and performance under control:

• Convert images to modern formats (WebP, AVIF).
• Use responsive images (different sizes for mobile/desktop).
• Offload heavy assets to a CDN.

If you’re new to CDNs, start with our explanation of what a Content Delivery Network (CDN) is and its advantages. If you already use one and worry about costs, our article on controlling CDN bandwidth costs with cache hit ratio and regional pricing goes deeper into strategy.

For video, compare a dedicated streaming platform or object storage + CDN with serving large MP4 files directly from shared hosting. Direct delivery from a VPS is also an option, but requires sufficient transfer allowance and peak network capacity. Assess CPU requirements for the actual workload rather than inferring them from video transfer volume alone.

3. Dynamic E‑Commerce and SaaS

For e‑commerce and SaaS, CPU and database IO can become bottlenecks even when network capacity remains available. Bandwidth still matters when:

• Product pages have many large images.
• You serve large JS bundles (dashboards, single‑page apps).
• You run APIs for mobile or partner integrations.

For these cases, combine bandwidth estimation with capacity planning for CPU, RAM and IOPS. Our articles on WooCommerce capacity planning (vCPU, RAM, IOPS) and when WooCommerce really needs separate database and cache servers can help if you’re scaling an online store.

Monitoring Real Usage and Knowing When to Upgrade

Estimates are only the starting point. Once your site runs on shared hosting or a VPS, you should validate and refine those numbers with real metrics.

Where to Check Bandwidth and Traffic

• Provider or control-panel counters: Check period, units, included protocols and whether ingress, egress or both are counted.
• Web logs: Sum the configured response-byte field. It may exclude headers, protocol overhead and non-web traffic, so it need not match the provider’s meter.
• Analytics: Sessions and pageviews estimate visitor activity; they are not byte counters.
• Network monitoring: Compare transferred-byte counter changes over a known interval or the rate shown by your monitoring system. Preserve its interval and unit when identifying peaks.

If you’re on a VPS and want a structured start, we’ve shared a practical approach in our guide to VPS monitoring and alerts with Prometheus, Grafana and Uptime Kuma.

Signs You’re Hitting Bandwidth or Resource Limits

Watch for:

• Noticeable slowdown during peak hours while off‑peak is fine.
• cPanel “Resource Limit Reached” messages or 508 errors.
• Frequent 5xx errors (500, 502, 503) under load.
• Very high CPU/IO usage in your panel or monitoring tools, even with caching enabled.

A plausible bandwidth estimate does not rule out network saturation. Correlate slow periods and 5xx errors with measured network throughput, CPU, RAM, storage metrics and error logs before choosing a remedy. If application or database work is the bottleneck, code optimization or appropriate caching may help more than extra bandwidth. For WooCommerce, exclude cart, checkout, account and session-specific responses from shared page caches. Choose a VPS with more suitable resources, including NVMe storage where storage is the measured constraint, rather than assuming an upgrade will fix every slowdown.

How Often to Revisit Your Estimates

We recommend:

• Every 3–6 months for stable sites.
• After major campaigns (Black Friday, product launches).
• Whenever you change design significantly (new theme, new image strategy, adding video).

Keep peak and percentile metrics tied to their sampling window. A 95th-percentile rate is not the maximum rate, and a larger averaging window can hide short bursts. Correlate sustained trends with usable capacity and application limits before planning an upgrade.

Reference 4: Active Downloads and CDN Byte Hits

Use these checks when a monthly total is insufficient. Each example states a separate quantity; none is a universal workload or a recommended port size.

Active Downloads Within a Shared Transfer Window

• 100 users are actively downloading at the same time.
• Each receives 2.5 decimal MB from the selected source.
• The shared data-transfer window is 2 seconds, excluding server wait and browser work.

Required payload rate (Mbps) = Active downloads × MB per download × 8 ÷ Transfer seconds.

100 × 2.5 × 8 ÷ 2 = 1000 Mbps = 1 Gbps before protocol overhead. With only 10–20 active downloads under the same assumptions, the result is 100–200 Mbps. Count active downloads rather than all open sessions.

These figures describe the stated synchronized transfer window. A full page-load deadline includes other work and cannot be substituted directly for transfer time.

For the reverse calculation, Transfer seconds = Payload MB × 8 ÷ Available payload Mbps. The available payload rate can be lower than the advertised port line rate.

A small monthly total does not rule out a demanding short interval. Check usable throughput and competing traffic, then measure whether the relevant endpoints meet the chosen transfer objective.

• Network sharing and rate limits can reduce usable capacity.
• Browser caching changes the bytes downloaded on repeat views.
• A CDN cache hit can shift the transfer away from the origin; server-side page caching alone does not remove response bytes.

For an implementation decision, compare transfer allowance and short-interval throughput separately. A shared plan may fit or a VPS may fit; the required numbers do not themselves establish which product has the appropriate limits.

Byte Hit Ratio Is Different from Request Hit Ratio

Let B be the bytes served to users through the measured CDN scope and h be the fraction of those bytes served from cache. A simplified origin estimate is B × (1 − h), before additional fills, revalidation traffic and other origin activity.

For 1 TB of user-facing transfer and an assumed 80% byte hit ratio:

1 TB × (1 − 0.8) = 0.2 TB = 200 GB of simplified origin transfer. This does not mean the user-facing data disappears, and an 80% request hit ratio does not imply 80% of bytes were cached.

Cache accounting must match the quantity being estimated. Revalidation may contact the origin while the response body comes from cache; request counts and transferred-byte views can therefore categorize it differently.

Track actual origin fetches and the provider’s transfer meter. A month-wide byte hit ratio is not automatically the byte hit ratio during the busiest second or hour.

Separate content classes before applying a ratio: cacheable images, public pages, dynamic responses and API traffic can behave differently. An aggregate percentage should not be applied to traffic outside its measured scope.

• Record user-facing CDN bytes, cached bytes and the reporting period.
• Record origin fetches and additional origin activity separately.

Optimization and cache rules should be evaluated with measured data and correct application behavior. The goal is a defensible transfer estimate, not a preset percentage reduction.

Cross-check Formula Results Without Inventing a Peak

The following independent arithmetic checks use decimal units. They are examples of volume conversion, not plans for specific customers:

8,000 pageviews × 1.2 MB = 9.6 GB; a 50% allowance gives exactly 14.4 GB. Choosing a rounded 15 GB allowance is a separate planning step, whose 30-day average is about 0.0463 Mbps.

30,000 pageviews × 5 MB = 150 GB; a 50% allowance gives 225 GB, averaging about 0.6944 Mbps over 30 days.

200,000 pageviews × 2.5 MB = 500 GB; a 50% allowance gives 750 GB, averaging about 2.3148 Mbps over 30 days.

None of these monthly averages supplies a measured peak. Use the active-download formula or observed shorter-interval transfer data for that separate question.

For equal viewing durations at the same average bitrate, GB = Average total bitrate in Mbps × Viewing seconds per viewer × Viewers ÷ 8000. If durations differ, sum the viewer-seconds; if average bitrates also differ, calculate each bitrate/duration group separately and add its volume. A hypothetical 4–8 Mbps stream watched for one hour transfers 1.8–3.6 GB per viewer, before overhead; 100 complete views transfer 180–360 GB.

For API response bodies, GB = Response count × Decimal KB per response ÷ 1,000,000. Here KB means 1,000 bytes. At 100 million responses and 20–50 KB each, the result is 2–5 TB. Add request bodies or headers only where they are not already counted; do not multiply a total request rate by user count again.

A network-volume estimate does not establish CPU, memory or database capacity. Keep those workload checks alongside the network calculations and apply any cache exclusion rules to personalized cart, checkout and account data.

Record the Inputs So the Estimate Can Be Reproduced

Keep the source period, units, transferred page bytes, session/pageview counts, additional transfers, cache scope and any allowance together. Record monthly average, busy-period average and short-interval demand as separate results. This makes errors in units or scope visible before a hosting decision.

For smaller, mostly static or lightly dynamic sites, well‑optimized shared hosting may be sufficient, especially with caching and a CDN where appropriate. For heavier e‑commerce, SaaS or media workloads, compare VPS plans by CPU allocation, memory, usable network capacity and administrative control. Do not assume that a VPS includes dedicated CPU cores or higher port speeds.

Replace assumptions with observations after launch and after meaningful traffic or content changes. Compare like-for-like periods and measurement boundaries. Retain the original calculation so the reason for any revised allowance or capacity target is clear.