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.
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.