Page Weight & Load Time Calculator

Understanding the page weight and load time calculator — concept and principle

This calculator gives a first-order estimate of how long a web page takes to load from two things: how many bytes must be downloaded and how many sequential network round trips stand in the way. It is useful for setting a page-weight budget, explaining why a fast connection still feels slow, and comparing the effect of shrinking files with the effect of cutting round trips.

Round trips are pure waiting; page weight is the carrying part.

How it is calculated

Transfer part (s) = page weight (KB) × (1 − compression saving ÷ 100) × 8 ÷ 1000 ÷ bandwidth (Mbps). Multiplying by 8 turns bytes into bits; dividing by 1000 turns kilobits into megabits.
Latency part (s) = sequential round trips × RTT (ms) ÷ 1000.
Estimated load time = transfer part + latency part.

KB here means 1000 bytes and Mbps means one million bits per second, the units used by network providers.

The principle

Any download pays two costs. Bandwidth limits how fast bits flow once data is moving, so time grows with size. Latency is the delay of one request-and-response trip, and some steps cannot start until the previous one finishes: a DNS lookup, the TCP handshake, the TLS handshake, fetching the HTML, then discovering and fetching render-blocking CSS and JavaScript. Those waits add up no matter how fast the link is. That is why on high-bandwidth links latency often dominates and the most effective optimisations remove round trips (preconnect, HTTP/2 or HTTP/3, inlining critical CSS, a CDN closer to users).

Worked example

Inputs: 2500 KB, 10 Mbps, RTT 80 ms, 6 round trips, 0% compression saving.
Bits to send: 2500 × 8 = 20,000 kilobits = 20 megabits.
Transfer part: 20 ÷ 10 = 2 s.
Latency part: 6 × 80 ÷ 1000 = 0.48 s.
Total: 2 + 0.48 = 2.48 s.

Each point is the calculator re-run with only “Connection (Mbps)” changed; the gold point is the default example. Change the inputs above and this chart follows your numbers.

Connection (Mbps)	Estimated load time (s)
2.5	8.48
5	4.48
7.5	3.146666667
10	2.48
12.5	2.08
15	1.813333333
20	1.48

How to read the result

Compare the two parts. If transfer dominates, reduce bytes: compress text, resize and modernise images, remove unused JavaScript. If latency dominates, reduce round trips or bring servers closer. Typical RTTs are a few milliseconds on a local network, roughly 20–50 ms on good fixed broadband and often 50–150 ms or more on mobile.

Common mistakes

Confusing megabytes (MB) with megabits (Mb); the factor is 8.
Using the advertised plan speed instead of the speed actually achieved.
Treating the result as when the page becomes usable; rendering and script execution add more time.

Keep in mind: This is a deliberately simple model. It ignores TCP slow start, parallel downloads, caching, packet loss, server processing and browser rendering, so real load times can differ substantially.

Frequently asked questions

Why does doubling my bandwidth not halve the load time?

Only the transfer part shrinks; the latency part stays the same.

How many round trips does a new HTTPS connection need?

Usually DNS, one for TCP and one or two for TLS (one with TLS 1.3) before the first request; HTTP/3 over QUIC combines transport and TLS setup.

What is a reasonable page-weight budget?

There is no official limit; many teams aim for well under 1–2 MB on mobile and set budgets per resource type.

Sources: Ilya Grigorik, High Performance Browser Networking, O'Reilly Media (2013) · IETF RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3

Checked 8 Nov 2026. Standard formulas and RFC/IEEE definitions, computed locally in your browser — nothing you type is sent anywhere.

Your numbers