free_tool
Web Performance Budget Calculator
A fast page is a budget you keep, not a hope you have. Set the total weight you're willing to ship, spend it across the resource types a page loads (HTML, CSS, JavaScript, images, fonts, third-party), add your backend TTFB, and see exactly where the weight goes and how long it takes to arrive on a real connection.
Budget remaining
72 KB
428 KB of 500 KB used · 86%
Heaviest: Images (160 KB).
Est. load on Fast 4G
590 ms
200 ms TTFB + 390 ms transfer at 9 Mbps effective
- HTML / document
- 16 KB3%
- CSS
- 24 KB5%
- JavaScript
- 140 KB28%
- Images
- 160 KB32%
- Fonts
- 48 KB10%
- Third-party / other
- 40 KB8%
Blowing your weight budget and the Lighthouse score won't move? I'll find what's actually on the wire and the cheapest kilobytes to cut.
Trim the payload: book a callTransfer sizes are over-the-wire (compressed) bytes. The load estimate is a single-connection approximation; real browsers parallelize requests, and JavaScript also costs main-thread parse and execute time on top of download. Allocating the weight is where every Core Web Vitals plan starts.
how_it_works
Why JavaScript is the tightest slice
Pick a total weight you want to defend (say 500 KB), then give each resource type its slice. The total either fits under the line or it doesn't, and the breakdown shows the one resource eating most of the page. On most sites that's images or JavaScript.
A kilobyte of JavaScript is the most expensive kind: the browser has to download it, then parse and execute it on the main thread, which is what stalls interaction (INP). Images you can usually compress or defer; shipped JS you have to actually delete. Treat the budget as a contract so the next dependency has to earn its weight.
faq
Questions & answers
- How does the Web Performance Budget Calculator estimate load time?
- You set a total page-weight budget and split it across HTML, CSS, JavaScript, images, fonts and third-party code, then add a backend TTFB. It estimates load time as TTFB plus the transfer time of those bytes over the connection speed you pick.
- Which connection speeds does it assume?
- It offers Slow 4G, Fast 4G and Broadband as effective payload throughput figures aligned with Lighthouse throttling, not the headline speeds carriers advertise. Pick the one closest to your real audience.
- Why is the default JavaScript budget so tight?
- A kilobyte of JavaScript costs you twice: once to download and again to parse and execute on the main thread, which delays interaction and hurts INP. Images can be compressed or deferred, but shipped JavaScript you have to delete, so the default keeps it on a short leash.
- Does it predict my Core Web Vitals scores?
- No. It models page weight and a single-connection load estimate, which is a prerequisite for good vitals but not a direct prediction. Real browsers also fetch resources in parallel, so treat the load time as a planning figure.
- Is any of my data sent anywhere?
- No. The whole calculation runs in your browser and nothing is sent to a server. Your budget is only written to the URL when you copy a shareable link.
Page weight out of control?
I'll profile what's actually on the wire (the heavy third-party scripts, the unoptimized images, the JS you can delete) and give you a budget the team can hold. Book a call, or leave your email.
Prefer proof first? See how this plays out in real case studies →