What exactly is a performance budget?

A performance budget is a set of limits on measurable aspects of your website's speed and size. It typically includes maximum values for total page weight in kilobytes, individual resource sizes (JavaScript, CSS, images, fonts), timing metrics (FCP, LCP, TTI, TBT), and visual stability scores (CLS). When any metric exceeds its limit, the budget is violated and the team needs to optimize before shipping. It works the same way a financial budget prevents overspending: you set the ceiling before you start, and you check every decision against it.

How is this different from running Lighthouse?

Lighthouse gives you a snapshot of your page's current performance. It tells you what the scores are today. A performance budget tells you what the scores must be. Lighthouse is the measuring tape; the budget is the blueprint. You use Lighthouse (or Lighthouse CI) to measure whether the page meets the budget, but the budget itself is the standard you are enforcing. Without a budget, Lighthouse scores are just numbers. With a budget, they become pass/fail criteria in your deployment pipeline.

What should my total page weight budget be?

It depends on your page type and your users' connection speeds. For a landing page targeting mobile users on 4G, aim for 500 KB or less total. For an e-commerce product page with images, 800 KB to 1 MB is reasonable. For a media-heavy news site with ads, 1.2 to 1.4 MB is a realistic ceiling. The calculator above gives you specific recommendations based on the page type and device profile you select. The key principle: if your page takes more than 5 seconds to become interactive on your target connection, the budget needs to be tighter.

Can I use this budget with Lighthouse CI?

Yes. This calculator exports a budget.json file formatted for Lighthouse CI. You place it in your project root or reference it in your Lighthouse CI configuration. When Lighthouse runs as part of your CI pipeline, it checks each metric against the budget and reports failures. Any metric that exceeds its threshold causes the audit to fail, which you can configure to fail the entire build. This is the recommended way to enforce budgets because it runs automatically on every pull request.

How do I create a budget for a site that is already slow?

Start by measuring your current performance with Lighthouse or WebPageTest. Then set a budget that is 20 to 30 percent tighter than your current numbers. This gives you an achievable first milestone. Once you consistently meet that budget, tighten it further in the next quarter. Trying to go from a 3 MB page to a 500 KB page overnight will fail. Progressive budgets work better than radical ones because they give the team time to learn optimization techniques while still making measurable progress.

What happens when a third-party script exceeds the budget?

Third-party scripts are the hardest budget items to control because you do not own the code. Your options are: defer loading the script until after the page becomes interactive, load it only when the user interacts with its feature (like a chat widget that loads on click), replace it with a lighter alternative that provides the same data, or negotiate with the vendor to reduce their script size. If none of those work, you may need to accept a higher budget for that specific resource, but document the decision and revisit it quarterly.

Should my budget be different for desktop and mobile?

Absolutely. Mobile devices have slower CPUs, less memory, and slower network connections than desktops. A 300 KB JavaScript bundle parses in 200 milliseconds on a modern laptop but can take 1.5 seconds on a mid-range phone. A performance budget that only targets desktop effectively has no constraint on mobile performance. Always set separate budgets or, at minimum, set the budget for the device profile that represents your slowest supported user. The calculator above lets you switch between device and network profiles to see how the same budget translates across conditions.

How often should I check my performance budget?

In CI: every pull request. In production: at least weekly for critical pages, monthly for less-trafficked pages. Set up automated Lighthouse CI runs on your main deployment branch so you catch regressions before they reach users. Use a monitoring service like SpeedCurve, Calibre, or DebugBear to track real-user Core Web Vitals over time and alert you when metrics degrade. The budget in CI prevents new regressions; monitoring in production catches existing ones that CI missed.

What exactly is a performance budget?

A performance budget is a set of limits on measurable aspects of your website's speed and size. It typically includes maximum values for total page weight in kilobytes, individual resource sizes (JavaScript, CSS, images, fonts), timing metrics (FCP, LCP, TTI, TBT), and visual stability scores (CLS). When any metric exceeds its limit, the budget is violated and the team needs to optimize before shipping. It works the same way a financial budget prevents overspending: you set the ceiling before you start, and you check every decision against it.

How is this different from running Lighthouse?

Lighthouse gives you a snapshot of your page's current performance. It tells you what the scores are today. A performance budget tells you what the scores must be. Lighthouse is the measuring tape; the budget is the blueprint. You use Lighthouse (or Lighthouse CI) to measure whether the page meets the budget, but the budget itself is the standard you are enforcing. Without a budget, Lighthouse scores are just numbers. With a budget, they become pass/fail criteria in your deployment pipeline.

What should my total page weight budget be?

It depends on your page type and your users' connection speeds. For a landing page targeting mobile users on 4G, aim for 500 KB or less total. For an e-commerce product page with images, 800 KB to 1 MB is reasonable. For a media-heavy news site with ads, 1.2 to 1.4 MB is a realistic ceiling. The calculator above gives you specific recommendations based on the page type and device profile you select. The key principle: if your page takes more than 5 seconds to become interactive on your target connection, the budget needs to be tighter.

Can I use this budget with Lighthouse CI?

Yes. This calculator exports a budget.json file formatted for Lighthouse CI. You place it in your project root or reference it in your Lighthouse CI configuration. When Lighthouse runs as part of your CI pipeline, it checks each metric against the budget and reports failures. Any metric that exceeds its threshold causes the audit to fail, which you can configure to fail the entire build. This is the recommended way to enforce budgets because it runs automatically on every pull request.

How do I create a budget for a site that is already slow?

Start by measuring your current performance with Lighthouse or WebPageTest. Then set a budget that is 20 to 30 percent tighter than your current numbers. This gives you an achievable first milestone. Once you consistently meet that budget, tighten it further in the next quarter. Trying to go from a 3 MB page to a 500 KB page overnight will fail. Progressive budgets work better than radical ones because they give the team time to learn optimization techniques while still making measurable progress.

What happens when a third-party script exceeds the budget?

Third-party scripts are the hardest budget items to control because you do not own the code. Your options are: defer loading the script until after the page becomes interactive, load it only when the user interacts with its feature (like a chat widget that loads on click), replace it with a lighter alternative that provides the same data, or negotiate with the vendor to reduce their script size. If none of those work, you may need to accept a higher budget for that specific resource, but document the decision and revisit it quarterly.

Should my budget be different for desktop and mobile?

Absolutely. Mobile devices have slower CPUs, less memory, and slower network connections than desktops. A 300 KB JavaScript bundle parses in 200 milliseconds on a modern laptop but can take 1.5 seconds on a mid-range phone. A performance budget that only targets desktop effectively has no constraint on mobile performance. Always set separate budgets or, at minimum, set the budget for the device profile that represents your slowest supported user. The calculator above lets you switch between device and network profiles to see how the same budget translates across conditions.

How often should I check my performance budget?

In CI: every pull request. In production: at least weekly for critical pages, monthly for less-trafficked pages. Set up automated Lighthouse CI runs on your main deployment branch so you catch regressions before they reach users. Use a monitoring service like SpeedCurve, Calibre, or DebugBear to track real-user Core Web Vitals over time and alert you when metrics degrade. The budget in CI prevents new regressions; monitoring in production catches existing ones that CI missed.

Performance Budget Calculator: Set Website Speed Limits That Match Your Industry

Test your website speed and performance instantly. Free online page speed test with Core Web Vitals analysis. No signup needed.

Performance Budget Calculator

Set performance targets, analyze pages, and generate Lighthouse configs

700 KB

Total Budget

622ms

Est. Load Time

Connection

PASS

Budget Status

Apply Preset

Target Configuration

Connection Speed

Target FCP1.8s

0.5s5s

Target LCP2.5s

1s8s

Target TTI3.8s

1s10s

Target CLS0.10

00.5

Target INP200ms

50ms500ms

Resource Budget Breakdown

Total:KB

Total Page Weight700 KB / 622ms est.

0 KBBudget: 2.5s on 4G

HTML

CSS

10%

JavaScript

35%

Images

35%

Fonts

Third-party

Other

HTML 5%

CSS 10%

JavaScript 35%

Images 35%

Fonts 8%

Third-party 5%

Other 2%