Performance Budget Calculator
Set performance budgets based on Core Web Vitals and connection speed.
Budget Overview
| Resource | Budget | Distribution | % |
|---|
Core Web Vitals Assessment
What is a Performance Budget?
A performance budget is a set of limits on the metrics that affect website performance, such as page weight, load time, and Core Web Vitals scores. It helps a team make deliberate decisions about what to include on a page and keeps performance within agreed thresholds instead of drifting as features are added.
This calculator works from two inputs: a connection profile and your target timings. From the connection it derives the effective bandwidth in bytes per second, and from your LCP target it estimates how many bytes the whole page can afford to ship. That total is then split across resource types using a fixed distribution so you can set per-asset limits.
The maths is straightforward. Bandwidth in kbps is converted to bytes per second, multiplied by the LCP target in seconds, and rounded to a total page weight. Round trips are estimated by dividing the LCP target by the connection's round-trip time, which hints at how many network exchanges you can afford.
Once the budget is calculated, each metric is graded against Google's recommended thresholds. Values at or below the good threshold grade as Good, values up to the poor threshold grade as Needs Improvement, and anything higher grades as Poor. An overall grade is derived from how many individual metrics are good.
Finally, the entire result is available as JSON. You can copy it into Lighthouse CI, a bundler performance hint, or a custom monitoring script so that the budget you set here becomes an automated gate in your pipeline.
Key Concepts
Page weight budget
The total bytes a page may transfer within the LCP target.
Connection profile
Bandwidth and latency of the network you are targeting.
Core Web Vitals
LCP, FID, and CLS, the metrics Google uses for page experience.
Resource split
The fixed percentage each resource type receives from the total.
Grading
Each metric is rated Good, Needs Improvement, or Poor.
JSON export
Copy the result into CI, bundlers, or monitoring tools.
How to Use
- Select connection type — Choose the target network speed (e.g., 4G for mobile users) or set a custom speed.
- Set Core Web Vitals targets — Adjust LCP, FID, CLS, TTI, and TBT targets based on your project requirements.
- Calculate — Click Calculate Budget to see the recommended page weight budget by resource type.
- Review assessment — Check how your targets grade against Google's recommended thresholds.
- Export — Copy the generated JSON to use with Lighthouse CI, webpack performance hints, or custom tooling.
Presets and Thresholds Reference
The calculator ships with a fixed set of connection profiles and a recognised set of Core Web Vitals thresholds. The tables below list both so you can pick sensible targets without guessing.
| Connection | Speed | RTT |
|---|---|---|
| Slow 3G | 50 kbps | 2000 ms |
| Fast 3G | 400 kbps | 800 ms |
| 4G | 3000 kbps | 170 ms |
| 5G | 10000 kbps | 50 ms |
| WiFi | 15000 kbps | 30 ms |
| Custom | your value | 100 ms |
| Metric | Good | Poor |
|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2500 ms | > 4000 ms |
| FID (First Input Delay) | ≤ 100 ms | > 300 ms |
| CLS (Cumulative Layout Shift) | ≤ 0.1 | > 0.25 |
| TTI (Time to Interactive) | ≤ 3800 ms | > 7300 ms |
| TBT (Total Blocking Time) | ≤ 200 ms | > 600 ms |
The total page weight is split across resources as follows: HTML 20%, CSS 15%, JavaScript 35%, images 20%, fonts 5%, and other assets 5%. JavaScript receives the largest share because it most often dominates load time.
Worked Examples
- 4G with default LCP of 2500 ms — a fast connection plus a tight target produces a small overall page weight, forcing careful asset trimming.
- WiFi with LCP of 2500 ms — the higher bandwidth yields a generously larger byte budget for richer pages.
- Slow 3G with LCP of 4000 ms — a slow network and a loose target show how quickly latency constrains the affordable page size.
- JavaScript share — whatever the total, JavaScript always receives 35% of it, the single largest slice.
- Round trips — with a 170 ms RTT and a 2500 ms LCP target, roughly 15 round trips are available; on Slow 3G at 2000 ms RTT, only about 2 fit.
- Grading effect — lowering the LCP target from 4000 ms to 2500 ms pulls the LCP grade from Needs Improvement up to Good.
Tips and Common Mistakes
- Budget for your slowest users — a budget tuned to WiFi looks great in the office and fails in the field, so test against mobile profiles.
- Treat the split as a guide — the percentages are a starting point; adjust them to reflect your actual asset mix.
- Watch JavaScript most closely — it holds the largest share and usually has the biggest impact on interactivity metrics.
- Set realistic RTT expectations — round-trip time drives the round-trip estimate and is often the real bottleneck, not raw bandwidth.
- Remember compression and caching — real transferred bytes are usually smaller than source size, so use compressed figures in your checks.
- Automate the budget — copy the JSON into CI so a regression fails the build instead of sliding by unnoticed.
Common Use Cases
Performance budgets turn a vague goal into a number the whole team can agree on. These are the situations where they help most.
- New project planning — agree on page weight limits before the first component is built.
- CI performance gates — fail a build when a pull request pushes a bundle over its budget.
- Third-party audits — measure the cost of analytics, ads, and widgets against the total allowance.
- Mobile-first design — size images and fonts for slow networks rather than assuming broadband.
- Stakeholder communication — express performance trade-offs as concrete byte and millisecond limits.
- Regression tracking — compare budgets over time to catch gradual bloat before it hurts Core Web Vitals.
Frequently Asked Questions
What is a performance budget?
A performance budget is a set of limits on metrics such as page weight and Core Web Vitals. It gives teams a concrete target to design and build against.
How is the total page weight calculated?
The connection speed in kbps is converted to bytes per second, multiplied by the LCP target in seconds, and rounded. The result is the total byte budget for the page.
Which Core Web Vitals are graded?
Five metrics are graded: LCP, FID, CLS, TTI, and TBT. Each is compared against a good and a poor threshold, and an overall grade is derived from the number of good metrics.
How is the budget split across resources?
HTML receives 20%, CSS 15%, JavaScript 35%, images 20%, fonts 5%, and other assets 5% of the total page weight.
What are the connection presets?
Slow 3G (50 kbps, 2000 ms RTT), Fast 3G (400 kbps, 800 ms), 4G (3000 kbps, 170 ms), 5G (10000 kbps, 50 ms), WiFi (15000 kbps, 30 ms), plus a custom speed option.
What RTT is used for a custom speed?
Custom connections use a fixed 100 ms round-trip time when estimating round trips.
What does the JSON output contain?
It includes the connection label, speed, RTT, target values, total page weight, the per-resource budgets, and the estimated number of round trips.
Is the calculation done on a server?
No. Everything runs in your browser, so no data is uploaded and the tool works offline once loaded.