Worksheet / Page transfer

Website transfer calculator.

This website transfer calculator estimates the data transferred by a stated number of page views. Enter traffic and measured page weight. Read the result in decimal GB, not server capacity.

Set the four inputs

For planning a business website or discussing an existing interface. No speed test, hosting recommendation or price estimate is produced.

Tervuq worksheetDecimal units / Explicit assumptions
01 / Website transfer calculator

Change the assumptions. Keep the units.

All four inputs describe the same workload. Select Calculate transfer after editing. Fractions are allowed for averages; visits and days are whole numbers.

MB means decimal megabytes: 1 MB = 1,000,000 bytes. GB means decimal gigabytes: 1 GB = 1,000 MB. These are not MiB or GiB.

Input registerFour quantities
visits/day

Whole number from 1 to 1,000,000. A visit is not the same as one person.

views/visit

From 1 to 100, in steps of 0.1. Use the average across the visits being estimated.

MB/view

Decimal megabytes, from 0.01 to 100 in steps of 0.01. Enter transferred bytes, not an uncompressed resource total.

days

Whole number from 1 to 366. A 30-day result is not automatically a calendar-month result.

These are the default example inputs. The live worksheet lets you change them; without JavaScript, use the formula below.

Estimated page transferDefault example

13.5 GB

Across 30 days

Total page views
9,000
Transfer per day
0.45 GB

The figure describes your inputs, not measured traffic on this site. Review a copied or carried summary before sending it to Tervuq.

Use this selectable text if clipboard access is unavailable. The initial text is the default worked example.

Default example: 9,000 page views and 13.5 GB over 30 days. The live worksheet appears here when its script is available.

02 / Arithmetic, not a forecast

The formula is multiplication.

No hidden traffic uplift. No assumed compression benefit. A uniform average is applied to each day in the chosen period.

A result can be numerically correct and still be a poor forecast. That happens when the page weight or the expected visit pattern is wrong.

Total page views
Visits per day × page views per visit × days
Period transfer in decimal GB
Total page views × MB per page view ÷ 1,000
Daily transfer in decimal GB
Visits per day × page views per visit × MB per page view ÷ 1,000
Worked example / Default values

100 visits, each viewing 3 pages

100 visits/day × 3 page views/visit = 300 page views/day. Over 30 days, that becomes 300 × 30 = 9,000 page views.

Each view transfers an entered average of 1.5 MB. Daily transfer is 300 × 1.5 = 450 MB. Dividing by 1,000 gives 0.45 GB/day.

Period transfer is 9,000 × 1.5 = 13,500 MB. Dividing by 1,000 gives 13.5 GB over 30 days. These figures are an example, not a report of Tervuq's visitors.

03 / Measure the right thing

A page weight needs a loading condition.

A first visit and a repeat visit may transfer different amounts. Record how you measured the page rather than treating one screenshot of a browser panel as a universal answer.

  1. Choose representative page journeys.

    A text-heavy service page is not a fair stand-in for a page that loads a large image collection. For business website development, use the mix people are expected to view, not simply the largest page you can find.

  2. Observe transferred bytes.

    Use the browser's network inspection panel and the transfer quantity for the selected page load. A resource's decoded size is not necessarily what crossed the network. Convert bytes to decimal MB by dividing by 1,000,000.

  3. Record cache behavior.

    Note whether it was a fresh browser visit or a repeat view with cached resources. If your average mixes those cases, make the mix deliberate. The calculator does not subtract a guessed cache saving.

  4. Keep the traffic definition consistent.

    Use visits and page views from the same intended reporting convention. Do not put unique people in the visits field and then multiply by a page-view average measured per session without first reconciling them.

04 / Interpretation limits

Transfer is not concurrency.

The website transfer calculator adds bytes across time. It does not ask when requests arrive, how long they run or what the application has to compute.

A quiet day can contain a sharp peak.

In the default example, 100 visits spread through a day and 100 visits arriving together produce the same entered daily total. Their server demands can be quite different. The tool has no arrival-time input, so it cannot estimate simultaneous users.

Concurrency needs observations about active requests and response duration. Neither comes from multiplying visits by page weight.

Small responses can require heavy work.

A short account response might depend on a slow database query. A larger static image might be served from a cache without that query. Byte volume alone does not tell you CPU use, available memory or database contention.

Do not pick a server size from this output. Application profiling and a workload-specific test answer a different question.

Uploads and additional API traffic are outside it.

The page-weight input does not automatically include a customer uploading a document or an open interface repeatedly requesting updates. Add only traffic already represented in your measured average; otherwise assess it separately.

Background requests can continue after the visible page looks finished. A short measurement window may miss them.

Bots and uncounted media are outside it too.

A traffic source that is absent from the visits input is absent from the answer. That includes bot requests you have not allowed for. Audio, streamed video and file downloads are excluded unless their transfer is already part of the entered page weight.

This tool does not identify abusive traffic or forecast a media audience. It does not add a safety factor behind the scenes.

05 / Signed-in workloads

A portal is not a public-page count.

Customer portal development often includes activity that a page-view total barely describes. A person can stay on one screen while the application keeps working.

Read about customer portals

A portal user might filter a record list, open a document and return to the same screen without a full page reload. Treating the session as one small page view would miss that transfer. Counting each interaction as a whole page would be another kind of mistake.

Use this estimate for the portion of the workload that your inputs actually represent. Describe polling, document sizes and role-specific journeys separately when discussing a portal. The same distinction matters for internal business tools that remain open throughout a work session.

Useful inquiry context

“These inputs cover public page loads only. The signed-in area also requests status updates while a user is active.” That is a better handoff than labeling a GB result as the application's capacity requirement.

For a public rebuild, transfer is one scoping question alongside content structure and editing requirements. The business website development page explains those decisions. For an existing slow interface, use the website technical support route rather than treating this calculator as a diagnosis.

06 / Optional review

Send the assumptions, not just the total.

Copy the summary or choose Include in an inquiry in the live result. On the contact page, the specification field is visible and editable. Check it before you submit. The calculation link carries only checked numeric inputs, not contact details; those values can appear in browser history and server logs. Calculating alone sends nothing.

The form is a request for a discussion, not an order. If the figures suggest a larger question about an interface, Tervuq can discuss a defined scope; the calculator itself does not price that work.