Monthly Traffic and Busy Hours: Worked Examples

The same website can average about 0.556 Mbps over a month, average about 5.333 Mbps during a selected busy hour and need 160 Mbps for a specified two-second group of transfers. Those figures answer different questions. This worksheet shows how to calculate each from explicit inputs instead of treating monthly GB as a port-speed recommendation.

Every numerical example here is synthetic: it is not a customer measurement, industry benchmark or traffic forecast. Copy the input table, replace its assumptions and keep monthly transfer, quota allowance, interval-average rates and short transfers separate. The examples use decimal MB/GB/TB and an exact 30-day period; choose your real accounting period when adapting them.

Set the Units and Measurement Boundary

Sessions and Pageviews Are Different Inputs

Use analytics metrics with the same period and scope. For page-transfer calculations, the useful distinction is:

• Users: A user count is not a session count; one user can start multiple sessions.
• Sessions: Periods of interaction as defined by the analytics system. In GA4 the default timeout is 30 minutes of inactivity, not a fixed 30-minute session length.
• Pageviews: Page-view events within the reporting period. They are not HTTP request counts, and their definition depends on analytics instrumentation.

Use recorded pageviews directly where available. Otherwise, sessions × pages/session estimates them. Do not multiply unique users by pages/session unless you also account for sessions per user. A session beginning in an hour does not imply all its pageviews occurred within that hour.

Volume, Rate and Time

Keep the units explicit:

• Decimal volume: 1 MB = 1,000,000 bytes; 1 GB = 1,000 MB; 1 TB = 1,000 GB.
• Binary volume: 1 MiB = 1,048,576 bytes; 1 GiB = 1,024 MiB. Dividing MB by 1,024 does not produce GB.
• Rate: 1 byte = 8 bits, and 1 MB/s = 8 Mbps. Mbps means one million bits per second.
• Period: Exactly 30 days contains 2,592,000 seconds. An average across that period is not a busy-hour average or a short-interval maximum.

The baseline below counts payload transferred directly from the selected origin. Third-party bytes, CDN-served bytes and uncompressed resource sizes are different quantities. The provider’s meter can include directions or overhead outside a browser measurement; record its accounting rules separately.

Measure the Bytes Represented by the Table

The size of a single page view is not just the HTML file. A typical page includes:

• HTML document
• CSS and JavaScript files
• Images (jpg, png, webp, svg, etc.)
• Fonts
• Sometimes video, audio or embedded widgets

Open Chrome DevTools before the page load and use the Network panel’s transferred-byte total, separately from its loaded/uncompressed resource total. Measure first visits with the browser cache disabled and repeat visits with it enabled. For origin planning, separate third-party transfers and use CDN/origin counters to account for cache misses.

Worked Example 1: Monthly Transfer and Quota Allowance

Step 1: Estimate your average page size

Measure representative pages and weight them by their share of pageviews and cache states. An unweighted mean is suitable only when that weighting is intended. For example:

1. List the page types and their transferred sizes from the chosen source.
2. Record each type’s share of pageviews, including first and repeat visits where relevant.
3. Multiply size by share and sum; keep the raw values until the final rounding step.

As a separate arithmetic illustration, suppose four page types have equal shares:

• Home page: 1.8 MB
• Blog post: 1.2 MB
• Product page: 2.5 MB
• Category page: 1.6 MB

The equal-share mean is (1.8 + 1.2 + 2.5 + 1.6) ÷ 4 = 1.775 MB. Rounding it to 1.8 MB changes the estimate slightly. The main input table instead assumes 2 MB; it does not claim that this value came from the four measurements above.

Step 2: Pages per visit

For the main worksheet, choose the same daily-session and pages/session inputs as the table:

• Pages per session: 3, as an explicit assumption.

This is not an assertion about an analytics account. Replace it with your actual same-period ratio when available.

Step 3: Monthly visits

The main worksheet assumes 1,000 sessions per day for an exact 30-day period:

• 1,000 sessions/day × 30 days = 30,000 sessions.

If you already have 30,000 sessions for the whole period, do not multiply that total by 30 again.

Page Transfer for the Main Worksheet

Now we can apply the basic formula:

Monthly page transfer (GB) = Daily sessions × Pages/session × Transferred MB/page × Days ÷ 1,000. This includes all page-load resources within the chosen measurement scope, not only HTML.

Using the example:

• Transferred MB/page: 2
• Pages/session: 3
• Monthly sessions: 30,000

First calculate data per visit:

Data per session = 2 MB × 3 = 6 MB.

Then monthly data:

Monthly page transfer = 6 MB × 30,000 = 180,000 MB = 180 GB. With E = 0 and the table’s 30% quota allowance, planned volume is 234 GB. An allowance is not measured consumption or evidence of peak capacity.

An Optional Download Row

Add transfer not already included in the page measurement. Avoid double counting when a page total already contains one of these:

• File downloads: PDFs, ZIPs, installers, etc.
• High‑resolution images or galleries (especially if loaded outside your main pages or via lightboxes).
• Self‑hosted videos or audio (if you don’t rely on external streaming platforms).
• API calls: Single‑Page Applications (SPA), mobile apps or embedded widgets.

For an independent additional-download assumption:

• A 25 MB PDF catalog
• 3,000 complete downloads in the period

Download transfer = 25 MB × 3,000 = 75,000 MB = 75 GB, before partial-download retries or other uncounted traffic.

Now total:

With that optional row, monthly transfer = 180 GB of pages + 75 GB of downloads = 255 GB.

Keep the Allowance Separate from the Baseline

Choose an allowance for uncertainty or growth and label it. Do not silently count every byte twice by adding overhead already included in the provider’s counter or the transferred-size measurement.

• The worksheet uses 30% as a chosen assumption, not a universal recommended margin.
• Known campaign traffic can be calculated as a separate period or workload; an arbitrary percentage does not recover its short peaks.

With the optional 75 GB download row and the same 30% allowance:

Planned monthly volume = 255 GB × 1.30 = 331.5 GB/month.

Compare 331.5 GB with a transfer allowance, not with a port speed. Whether a shared plan, VPS or dedicated service fits also depends on usable Mbps, sharing terms and CPU/RAM/IO limits.

Reuse the Worksheet for Other Explicit Assumptions

Start from realistic traffic scenarios

Without history, choose low, middle and high input sets from your own audience and campaign plan. The following values are illustrative alternatives, not predicted growth milestones:

• Scenario A: 100 sessions/day
• Scenario B: 1,000 sessions/day
• Scenario C: 5,000 sessions/day

Choose pages/session independently. Example ranges for exploring sensitivity, not measured site-type averages:

• Content sites/blogs: 2–4 pages per visit.
• Corporate/landing sites: 1.5–3 pages per visit.
• E‑commerce: 4–8 pages per visit (listing, filters, product pages, cart, checkout).

We also recommend reading our guide on how much CPU, RAM and bandwidth a new website really needs to align compute and network planning from day one.

Measure or estimate your initial page weight

Measure transferred bytes on a development or staging site where possible. If you use estimated inputs, label them and replace them after launch. These ranges are only hypothetical choices:

• A lighter page: 0.8–1.5 MB
• Another page design: 1–2 MB
• An image-heavy page assumption: 2–5 MB
• A product-page assumption: 1.5–3 MB

Work through an example for a new store

For a separate, hypothetical store calculation, choose:

• Transferred MB/page: 2.2
• Pages/session: 5
• Daily sessions: 1,500 throughout a 30-day period

Monthly visits ≈ 1,500 × 30 = 45,000

Data per visit = 2.2 MB × 5 = 11 MB

Monthly page transfer = 11 MB × 45,000 = 495,000 MB = 495 GB.

If this independent scenario uses a chosen 20% allowance:

495 GB × 1.20 = 594 GB/month.

594 GB is the planned monthly volume for those assumptions. A rounded 600 GB allowance would leave only 6 GB beyond that plan; it does not establish burst capacity. Compare shared, VPS and dedicated server limits without inferring a product requirement from volume alone.

Four More Synthetic Profiles with the Same 30% Allowance

All four rows use an exact 30-day period and zero additional transfer. Labels are illustrative, not measured site-type averages. Busy-hour inputs are independently specified; none is a port recommendation.

The store’s 30% plan is 2.0475 decimal TB, so a 2 TB allowance would be below that plan. For SaaS, keep 17.28 GB/day unrounded before multiplying by 30. Network figures alone do not establish application or database capacity.

Worked Example 2: Monthly Average Versus Busy-Hour Average

For the main table, 180 GB over 30 days gives 180 × 1,000 × 8 ÷ 2,592,000 ≈ 0.556 Mbps. The 234 GB allowance spread across the same period would average about 0.722 Mbps. Neither figure is a port-speed target. With 1,200 pageviews at 2 MB each in one hour, the busy-hour average is 1,200 × 2 × 8 ÷ 3,600 ≈ 5.333 Mbps.

Use Events Within the Hour, Not Request Counts

For a separate worked case, choose a busier day and explicitly assign activity to one hour:

• 3,000 sessions begin during the selected day.
• As an assumption, 20% begin in the selected hour.

The hour therefore contains 600 session starts. To turn this into pageviews, one further assumption is necessary:

• Each of those 600 sessions generates exactly two pageviews within that same hour.
• For this isolated example, other sessions generate no pageviews in that hour.

Example:

• 600 × 2 = 1,200 pageviews within the hour.
• Use 1.8 MB per page for this separate example, rather than the main table’s 2 MB.

Pageview rate averaged across the hour = 1,200 ÷ 3,600 = one third of a pageview per second. This is not HTTP requests per second: a pageview can trigger several HTTP requests. Keep the fraction unrounded until after the rate calculation.

Convert the Hour’s Bytes to Mbps

With the separate 1.8 MB assumption, calculate:

Average MB/s = 1.8 × (1,200 ÷ 3,600) = 0.6 MB/s.

Then convert bytes to bits:

Busy-hour average = 0.6 MB/s × 8 = 4.8 Mbps.

Avoid rounding the pageview rate before converting:

Rounding one third to 0.3 before multiplying would yield 4.32 Mbps and understate this example. Preserve precision through the calculation, then round the displayed result.

Protocol overhead, uncounted API calls and retries may add bytes. Add them only if they fall outside the current measurement boundary; do not add CSS/JS again when page size already includes it.

An arbitrary 10, 20 or 25 Mbps target does not follow from the 4.8 Mbps hourly average. Short intervals can have much higher demand. For the main table’s synchronized transfer case, 20 active downloads × 2 MB × 8 ÷ 2 seconds = 160 Mbps of payload rate before overhead; this uses active downloads, not all open sessions.

Understanding port speed vs real‑world usage

An advertised 100 Mbps or 1 Gbps port identifies a line-rate condition, not a promise that the account always has that much usable payload throughput. Check sharing, limits and any explicit guarantee. The two-second window above is for data transfer only; server response wait and browser processing also contribute to a full page-load time.

Add CDN and Cache Scope Without Double Counting

Browser and server‑side caching

Caching affects several different parts of the workload. Keep them distinct when changing the worksheet:

• Browser caching: Cache-Control and ETag participate in freshness and validation. Reuse can avoid a response-body download; revalidation may still involve network traffic.
• Server-side page caching: Can reduce repeated application/database work for suitable content; it does not by itself remove the response bytes sent to the user.

Our guide on cache‑busting strategies with browser and CDN caching explains how to set caching rules without breaking updates, which indirectly stabilizes your bandwidth usage.

Content Delivery Networks (CDNs)

A CDN can serve cacheable content from its edge rather than fetching each response from the origin. Track:

• User-facing CDN transfer and its price/allowance
• Origin fetches, origin transfer and the provider’s accounting period

For a simplified volume calculation, use the fraction of bytes served from cache, not the fraction of requests. For example:

• Assumed user-facing transfer of 1 TB with an 80% byte hit ratio gives 1 TB × 0.20 = 200 GB of simplified origin transfer.
• Additional fills, revalidation traffic and traffic outside that measured scope must be counted separately.
• An 80% request hit ratio does not prove 80% byte savings, and a monthly byte ratio need not hold during the busiest hour.

For an overview of when CDNs make sense, see our article what a CDN is and when you really need one.

Image and media optimization

Where media contributes substantially to transferred bytes, test file-size reductions while checking visual quality and browser support:

• Compare supported formats such as WebP or AVIF at suitable quality.
• Resize images for their displayed dimensions; a 5,000 px original may be unnecessary for a 350 px thumbnail.
• Select quality by testing the actual asset, rather than treating an encoder quality number as a universal setting.
• Lazy-load suitable offscreen images while preserving the intended page behavior.

See image SEO and hosting infrastructure using WebP/AVIF and CDNs for related choices. Re-measure transferred bytes afterward; no fixed percentage reduction is promised.

Special Cases: E‑Commerce, SaaS, APIs and Heavy Downloads

E‑commerce websites

For a store-specific input set, account for the actual mix of listing, product and checkout activity:

• Pageviews/session depends on the customer journey.
• Page types can have different transferred sizes.
• Personalized cart, checkout, account and session-specific responses should remain outside shared page caches.

For WooCommerce or similar platforms:

• Measure listing, product and checkout transfers separately.
• Weight by an explicit journey or measured pageview shares; do not add cart/checkout bytes again if already counted.
• Model known campaign periods separately and label any remaining allowance.

If you expect serious growth, our WooCommerce capacity planning guide explains how to size vCPU, RAM and IOPS alongside bandwidth so that your store remains responsive.

SaaS, APIs and SPAs

Applications with heavy API usage (SaaS dashboards, React/Vue SPAs, mobile apps) behave differently:

• The initial page load may be heavy (JS bundles, CSS, initial data).
• Subsequent interactions happen through smaller JSON API calls.

To calculate bandwidth:

• Initial transferred page data, for example an assumed 2.5 MB
• Separate response payload, for example an assumed 20–50 decimal KB per call
• Total calls in the period, or calls per active user per unit time with the relevant active-user count and duration

If you already know the total request count or total request rate, do not multiply by user count again. A rate needs its active duration before it becomes a monthly volume. Initial-page API responses already included in page size must not be counted twice. Here KB means 1,000 bytes.

Download or media‑heavy sites

If your site is mainly used for file distribution or media streaming, the classic “pages per visit” approach is secondary. Instead, focus on:

• Average file size and monthly download count.
• Average video bitrate and average viewing duration.
• Concurrency: how many users download or stream at the same time.

A hypothetical 1 GB installer downloaded completely 1,000 times transfers 1 TB, before retries and other traffic. Compare the relevant hosting, object-storage/CDN, dedicated or colocation prices and limits; high volume alone does not establish which is cheapest. Streaming calculations instead need the actual average bitrate and total viewing duration.

Monitoring and Adjusting: Turning Estimates Into Real Data

Use analytics plus server metrics

After launch, replace assumptions with observed inputs while keeping the measurement scope unchanged:

• Analytics: Sessions and pageviews provide activity counts, not the provider’s byte meter.
• Provider or panel: Check period, units, direction and included protocols for transfer accounting.
• Server logs: Check the response-byte field; it may exclude headers, protocol overhead or non-web traffic.
• Network monitoring: Retain the sampling interval and rate unit. Hourly averages, short-interval peaks and percentiles are different statistics.

If you want to go deeper into reading server logs, our article how to read web server logs on Apache and Nginx explains the basics, which also helps to validate your bandwidth predictions.

Track monthly patterns and peaks

Over a few months, look for:

• Monthly traffic trend: flat, slowly growing, or spiky.
• Daily and hourly patterns: which hours generate the most load.
• Which pages or files consume the most bandwidth.
• The impact of marketing campaigns or content launches.

This data lets you refine your formulas: update average page size, pages per visit and safety margins so your capacity planning is always grounded in reality.

Prepare for seasonality and campaigns

Many sites have predictable seasonal peaks: holidays, tax season, course enrollments, ticket launches, etc. Before those periods, you should:

• Choose campaign inputs from evidence or label them as assumptions.
• Estimate volume and activity within specific time windows, not only a multiplier of the month.
• Compare usable network capacity and application limits; validate any upgrade or cache change.

Our guide on preparing hosting for seasonal traffic spikes goes deeper into concrete scaling tactics that complement the bandwidth calculations in this article.

Compare the Worksheet Results with Hosting Conditions

Shared hosting

Shared hosting is a candidate when:

• Its transfer allowance and accounting rules cover the calculated period.
• Its usable network and resource limits cover the actual short-interval workload.
• Its operational features meet the application’s requirements.

A monthly amount such as 200–300 GB is not a universal shared-hosting boundary. Check CPU/RAM/IO and network observations as well as quota.

VPS hosting

Consider a VPS when it supplies required capacity or control that your existing plan does not:

• Compare transfer allowance with the complete volume estimate.
• Check vCPU, memory, network sharing and any guarantees; a VPS does not automatically provide dedicated CPU or network capacity.
• Confirm support for the application stack and the operational work it requires.

Available port options, caching and server configuration depend on the plan and software. For related trade-offs, see cutting hosting costs by right-sizing VPS, bandwidth and storage.

Dedicated servers and colocation

Dedicated servers and colocation can be evaluated when hardware, operational control or sustained resource needs justify them:

• Document which hardware and port resources are actually controlled or reserved.
• Compare transit, transfer allowance and overage terms.
• Plan redundancy and operations separately; a service category does not create them automatically.

Keep the same worksheet inputs when comparing offers. A higher monthly allowance does not compensate for insufficient short-interval throughput, and a faster port does not remove a monthly transfer cap.

Repeat the Calculation from a Saved Input Table

To make the worksheet reproducible:

1. Record period, sessions, pages/session, transferred MB/page and source scope.
2. Calculate monthly GB with the correct 1,000 conversion; do not multiply an already-monthly session count by days again.
3. Add only transfers outside the existing page measurement and show the allowance separately.
4. Convert monthly GB × 1,000 × 8 ÷ period seconds to the monthly average.
5. Convert busy-hour pageviews × that hour’s MB/page × 8 ÷ 3,600 to its average.
6. Calculate active concurrent transfers over their own transfer window and check actual capacity.
7. Track CDN/origin counters separately and replace assumptions with like-for-like measurements.

Keep Five Results Separate

The completed worksheet should show baseline monthly transfer, planned quota, monthly average Mbps, busy-hour average Mbps and the short-transfer assumption in separate rows. Keep the original values before rounding. This prevents a volume estimate from being mistaken for peak capacity.

Update the relevant input after campaigns, page changes or a meaningful usage trend. Preserve the previous estimate so the difference can be explained. For formula definitions and separate download, video, API and byte-hit calculations, use the traffic and bandwidth calculation reference.