Performance Budget Calculator
Page weight and a connection speed give a rough transfer time — a quick sanity check on whether a page is too heavy. Transfer only; latency and render are extra. Your own numbers.
Rough load time from page weight
Transfer time only — excludes latency and render. A sanity check, not a Lighthouse score.
The Performance Budget Calculator estimates download time using the formula: Download Time (seconds) = (Page Weight in bytes) / (Effective Connection Speed in bits per second) × 8. Here, Page Weight is the total size of all resources (HTML, CSS, JavaScript, images, fonts, etc.) transferred over the network, measured in bytes. Effective Connection Speed is the realistic throughput in bits per second (bps), typically 70-80% of the nominal speed due to overhead (TCP handshake, packet loss, protocol inefficiencies). The factor of 8 converts bytes to bits because connection speed is measured in bits per second. This calculation gives the raw transfer time, assuming a single, uninterrupted download with no parallelism. In practice, browsers use multiple connections (typically 6 per domain), so actual time may be lower if resources are spread across domains. However, this formula provides a conservative upper bound for the transfer phase. Latency, DNS resolution, TLS negotiation, and rendering time are not included—they add significant overhead. The formula is intentionally simple for quick sanity checks: if the estimated transfer time exceeds 3 seconds on a typical 4G connection, the page is likely too heavy. It helps developers set a performance budget by linking page weight to user experience.
E-commerce product page
An online store's product page weighs 2.5 MB (2,500,000 bytes). The target audience uses 4G with a nominal speed of 20 Mbps. Effective speed = 70% of 20 Mbps = 14 Mbps = 14,000,000 bps. Transfer time = (2,500,000 × 8) / 14,000,000 = 20,000,000 / 14,000,000 ≈ 1.43 seconds. This is under 2 seconds, acceptable for e-commerce. However, adding latency (e.g., 50 ms) and render time (1 second) would push total to ~2.5 seconds, still reasonable.
News article with heavy images
A news site's article page is 4 MB (4,000,000 bytes). The typical user has a 3G connection with nominal 5 Mbps. Effective speed = 75% of 5 Mbps = 3.75 Mbps = 3,750,000 bps. Transfer time = (4,000,000 × 8) / 3,750,000 = 32,000,000 / 3,750,000 ≈ 8.53 seconds. This is far above the 3-second budget, indicating the page is too heavy for 3G. Optimization: compress images, lazy-load below-fold content, or reduce script size.
SaaS dashboard (logged-in)
A business SaaS dashboard loads 1.2 MB (1,200,000 bytes) of dynamic content. Users are on office Wi-Fi with nominal 100 Mbps. Effective speed = 80% of 100 Mbps = 80 Mbps = 80,000,000 bps. Transfer time = (1,200,000 × 8) / 80,000,000 = 9,600,000 / 80,000,000 = 0.12 seconds. This is fast, but latency (e.g., 20 ms) and JavaScript execution (1 second) dominate. The transfer time is negligible; the budget should focus on render performance.
A good performance budget for transfer time depends on the target network. For mobile (4G), aim for under 2 seconds; for 3G, under 3 seconds; for desktop broadband, under 1 second. These are not industry averages but reasonable thresholds based on user expectations—pages over 5 seconds see high bounce rates. However, transfer time alone is insufficient; total page load time includes latency (typically 50-150 ms per request), DNS, TLS, and rendering (often 1-3 seconds for complex pages). If transfer time exceeds 2-3 seconds, the page is likely too heavy. For heavy pages, consider reducing image sizes, removing unused CSS/JS, or using CDNs. Note that connection speeds vary widely: 4G can range from 5-50 Mbps, and Wi-Fi from 10-100+ Mbps. Always test on the slowest acceptable connection for your audience. A good rule: keep page weight under 1 MB for fast mobile transfer (under 1 second on 4G). Use this calculator as a quick check, not a final measurement—real-world tools like WebPageTest account for parallelism and overhead.
A common mistake is using nominal connection speed instead of effective speed (70-80% of nominal). Overhead from TCP, encryption, and network congestion reduces throughput. Another mistake is ignoring that browsers use parallel connections—this formula assumes a single stream, overestimating time for multi-domain resources. Edge cases: very small pages (under 100 KB) are dominated by latency, not transfer time, making the formula less useful. For HTTP/2, multiplexing reduces overhead, but the formula still provides a conservative bound. Also, this calculation does not account for progressive rendering (e.g., lazy-loaded images) or service workers that cache resources. Users often forget to include all resources: third-party scripts, fonts, and tracking pixels can add significant weight. Finally, the formula assumes no compression; actual transfer may be smaller if the server uses gzip or Brotli. Always measure page weight after compression for a more accurate estimate.
- Page Weight
- The total size of all resources (HTML, CSS, JavaScript, images, fonts, etc.) transferred to render a web page, measured in bytes.
- Effective Connection Speed
- The realistic throughput of a network connection after accounting for overhead, typically 70-80% of the nominal speed.
- Transfer Time
- The time required to download all page resources over the network, calculated as page weight (in bits) divided by effective connection speed.
- Latency
- The time delay for a data packet to travel from client to server and back, usually 10-150 ms, which adds to total load time beyond transfer.
- Performance Budget
- A predefined limit on page weight, transfer time, or other metrics that a page must not exceed to ensure acceptable user experience.
Does this calculator include server response time?
No, it only estimates transfer time. Server response time (time to first byte) adds additional delay.
What connection speed should I use for mobile users?
Use a typical 4G speed of 10-20 Mbps (effective 7-15 Mbps) or 3G at 5 Mbps (effective 3-4 Mbps). Adjust based on your audience.
Why multiply by 8?
Because page weight is in bytes but connection speed is in bits per second. There are 8 bits per byte.
Should I use compressed or uncompressed page weight?
Use compressed weight (as served by the server) for a more accurate estimate, since most servers use gzip or Brotli.
Does this work for HTTP/2?
Yes, but HTTP/2's multiplexing can reduce transfer time further. The formula gives a conservative upper bound.
What is a good transfer time target?
Under 2 seconds for mobile 4G, under 3 seconds for 3G, and under 1 second for desktop broadband.
Why is my actual load time longer than this estimate?
The formula ignores latency, DNS, TLS, and rendering time. These can add 1-3 seconds or more.
Apex components and Motion are built performance-first, so pages stay well under the weight that slows load.
Startup Cost Calculator
Add up what it really takes to launch — and what a bundle replaces.
Service Pricing Calculator
Price every job for profit, not guesswork.
Break-Even Calculator
The exact number of jobs that turns the lights green.
Revenue Goal Calculator
Reverse-engineer the leads behind your number.
Catalog ROI Calculator
The time and money the catalog hands back every year.