Web Performance Budget Calculator
Set transferred-size limits for scripts, images, styles, and fonts. Compare planning scenarios, then export a Lighthouse CI configuration that can fail a build over budget.
A web performance budget is a set of resource or timing limits that a team checks during delivery. This calculator estimates a scenario from the values you enter. It does not load or measure your website, so confirm the result with lab tests and real-user data.
Maaz Rana builds and maintains this tool for Design Overflow. Updated .
Loading Performance Budget Calculator...
Why Performance Budgets Matter
Give each page template a limit the team can check before release
Catch Regressions Before Release
A resource-size limit turns a heavier script, image, or font into a visible build failure before the change reaches users.
Make Tradeoffs Explicit
A shared budget gives design and development teams a number to use when a new feature adds weight to a page.
Protect Slower Sessions
The same payload takes longer to download and process on slower connections and lower-powered phones. Budget for the audience you serve.
Connect Lab and Field Data
Use CI checks to prevent build regressions, then compare the result with Core Web Vitals from real visits.
How Performance Budgets Work
Measure the page, set the constraint, and make CI enforce it
Measure a Representative Page
Record transferred sizes and requests with Lighthouse, PageSpeed Insights, WebPageTest, or the browser network panel.
Choose the Constraint
Set limits for scripts, images, styles, fonts, and total transferred size. Use the calculator estimate as a planning aid.
Export a CI Configuration
Download the Lighthouse CI file and add the page URLs your build should test.
Review Exceptions
If a release exceeds the budget, reduce the payload or document the tradeoff before changing the limit.
Understanding Core Web Vitals
Use field data for LCP, INP, and CLS, then use lab tools to diagnose regressions
| Metric | Description | Target Values |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading experience, measured from real visits at the 75th percentile. | ≤ 2.5s> 2.5s to 4s> 4s |
| Interaction to Next Paint (INP) | Responsiveness across user interactions. Lighthouse uses Total Blocking Time as a lab proxy. | ≤ 200ms> 200ms to 500ms> 500ms |
| Cumulative Layout Shift (CLS) | Visual stability across the lifetime of the page. | ≤ 0.1> 0.1 to 0.25> 0.25 |
Google assesses Core Web Vitals at the 75th percentile, split across mobile and desktop. Read the current Web Vitals guidance.
Bring a Build Back Under Budget
Start with the resource category that changed, then measure the page again
Resize and Encode Images
Match source dimensions to rendered dimensions, choose a suitable format, and keep the LCP image out of lazy loading.
- Inspect image transfer sizes in the network panel
- Provide responsive candidates with srcset or framework tooling
- Set width and height to reserve layout space
- Measure the converted file before replacing the source
Reduce JavaScript Work
JavaScript costs network time and main-thread work. Start with code that loads before the page becomes usable.
- Remove unused dependencies and duplicate packages
- Split code by route or interaction
- Delay third-party scripts that do not support the first task
- Compare Total Blocking Time before and after the change
Control Font Loading
A font budget should cover the files and character sets the initial view needs.
- Subset font files to the languages you ship
- Load fewer families and weights
- Use font-display to define fallback behavior
- Check whether a system stack meets the interface need
Budget Third-Party Code
Analytics, embeds, chat widgets, and tag managers can add requests and CPU work outside the main bundle.
- List each third-party owner and purpose
- Load scripts after consent and at the point of need
- Remove tags that no team uses
- Test the page with and without each provider
Measure the Page Before Changing the Budget
Use field data for the user result and lab tools for repeatable diagnosis
PageSpeed Insights
Shows Lighthouse lab results and Chrome UX Report field data when the page has enough eligible traffic.
Use it to compare a controlled test with the experience of Chrome users.
Chrome DevTools Performance
Records loading, rendering, and main-thread work while you reproduce a slow interaction.
Use it to find the work behind a poor lab result.
WebPageTest
Runs repeatable tests with chosen locations, devices, connections, and detailed request waterfalls.
Use it to inspect discovery chains and compare test runs.
Lighthouse CI
Runs Lighthouse during delivery and checks assertions against the configuration in your repository.
Use it to stop a measured regression from merging or deploying.
Set a Budget Your Team Can Maintain
Base the first limit on a measured page, then tighten it with each verified improvement
Start From Measured Transfer Sizes
Record the current page before setting a lower limit. A first budget can match today’s build and tighten after you remove known waste.
Separate Page Templates
A marketing page, article, product listing, and application screen have different payloads. Give each template its own path and limits.
Budget for Your Users
Choose device and network assumptions from your audience data. Recheck field metrics across mobile and desktop at the 75th percentile.
Keep an Exception Record
A larger budget should name the feature, measured cost, owner, and review date. Silent increases remove the constraint.
Calculator Preset Starting Points
Editable examples included with the tool. Replace them with limits from your measured page
| Page type | JavaScript | Images | Total | Intended use |
|---|---|---|---|---|
| Landing page | 150 KB | 200 KB | 530 KB | Focused marketing page with one main conversion path |
| Article | 100 KB | 300 KB | 625 KB | Editorial page with supporting media |
| Product listing | 200 KB | 400 KB | 930 KB | Image-led catalogue or commerce template |
| Application screen | 300 KB | 150 KB | 750 KB | Interactive screen after the application shell loads |
Web Performance Budget References
Primary documentation for the field metrics, budget format, and CI assertions used on this page
Core Web Vitals
Google’s current field metrics, thresholds, 75th-percentile assessment, and lab limitations.
Lighthouse performance budgets
Google’s format for timing, resource-size, and request-count budgets.
Lighthouse CI configuration
The current assertion syntax, file-size units, and budgetsFile option from the Lighthouse CI project.
Questions About Performance Budgets
Common questions about setting, enforcing, and measuring web performance budgets
A web performance budget sets limits for page resources or timing metrics. A team can cap transferred JavaScript, images, total page weight, request counts, or lab timings, then check each build against those limits. The budget gives a release process a testable constraint instead of a broad request to make the site faster.
No. The calculator uses the resource sizes, device profile, and connection profile you choose to produce a planning estimate. It does not load a URL or measure server response time, request order, caching, compression, third-party work, or real-user behavior. Use PageSpeed Insights, Lighthouse, WebPageTest, or your real-user monitoring to measure a page.
The current Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Check them at the 75th percentile of visits, split across mobile and desktop. Lighthouse cannot measure INP without real interaction, so use Total Blocking Time as a lab diagnostic and field data for the user result.
Time to Interactive remains a lab metric outside Core Web Vitals. This calculator includes a rough TTI estimate to compare budget scenarios. Use LCP, INP, and CLS from field data for the current Core Web Vitals assessment.
The export creates a lighthouserc.json file with resource-summary assertions. Lighthouse CI reads file-size limits in bytes for that assertion format. Add the URLs or start-server command for your project, run lhci autorun, and let the build fail when a resource category exceeds its limit.
Use one budget for pages that share a template and loading pattern. Create separate limits for pages with different jobs, such as a landing page and a signed-in dashboard. Lighthouse budget files can target URL paths, while Lighthouse CI configurations can apply assertions to the pages collected in a run.
Need the Page Measured and Fixed?
Share the slow page and the device or market that matters. Design Overflow can trace the bottleneck, implement the changes, and add a budget to the delivery process.
Discuss Web Performance