What Is a Performance Budget?
A performance budget is a set of limits on metrics that affect user experience. It's a threshold you agree not to exceed. When a metric crosses the budget, it triggers a review, an alert, or a rollback — just like a financial budget triggers action when you overspend. For the metrics behind these budgets, see What Are Core Web Vitals?.
Performance budgets aren't aspirational goals. They're hard constraints. The difference matters: a goal is something you aim for; a budget is something you enforce.
Why Performance Budgets Work
Without budgets, performance degrades gradually. It's the "boiling frog" problem: no single change makes the site noticeably slower, but over months of new features, additional scripts, and growing page weight, performance erodes until someone finally notices — usually a client, a user, or Google.
Performance budgets prevent this by making degradation visible and actionable the moment it happens.
Benefits of Performance Budgets
- Prevent gradual degradation — Every change is checked against the budget
- Create accountability — The team knows what "too slow" means, concretely
- Enable automation — Budgets can trigger alerts, block deploys, or flag regressions
- Simplify decision-making — "Does this change break the budget?" is a yes/no question
- Improve client communication — "Your site is within budget" is clear and reassuring
Types of Performance Budgets
1. Metric-Based Budgets (Recommended)
Set limits on Core Web Vitals and related metrics:
| Metric | What It Measures | Recommended Budget |
|---|---|---|
| LCP | Largest Contentful Paint | ≤ 2.5 seconds |
| INP | Interaction to Next Paint | ≤ 200 milliseconds |
| CLS | Cumulative Layout Shift | ≤ 0.1 |
| FCP | First Contentful Paint | ≤ 1.8 seconds |
| TBT | Total Blocking Time | ≤ 200 milliseconds |
| Speed Index | Visual completeness over time | ≤ 3.4 seconds |
| Performance Score | Lighthouse composite score | ≥ 90 |
Metric-based budgets are the most practical because they directly correspond to what Google measures and what users experience.
2. Resource-Based Budgets
Set limits on the resources that make up a page:
| Resource | Recommended Budget |
|---|---|
| Total page weight | ≤ 1.5 MB (compressed) |
| JavaScript (total) | ≤ 300 KB (compressed) |
| CSS (total) | ≤ 100 KB (compressed) |
| Images (total) | ≤ 500 KB |
| Third-party scripts | ≤ 100 KB (compressed) |
| Font files | ≤ 100 KB |
Resource-based budgets are useful during development but less directly tied to user experience. A page can be over the resource budget but still perform well (or vice versa).
3. Quantity-Based Budgets
Set limits on the number of resources:
| Item | Recommended Budget |
|---|---|
| HTTP requests | ≤ 50 |
| Third-party domains | ≤ 5 |
| JavaScript files | ≤ 10 |
| Font files | ≤ 3 |
| Render-blocking resources | 0 |
Quantity budgets are easy to enforce but can be gamed (bundling everything into one massive file passes the "number of files" budget but creates other problems).
Which Type Should You Use?
Start with metric-based budgets. They're the most meaningful because they measure what users actually experience. Add resource-based budgets as guardrails for development. Use quantity-based budgets sparingly — they're useful for specific constraints (like limiting third-party script count) but shouldn't be your primary tool.
How to Set Performance Budgets
Step 1: Baseline Your Current Performance
Before setting budgets, you need to know where you stand. Run PageSpeed Insights on your key pages (homepage, landing pages, conversion pages) for both mobile and desktop.
Record the current values:
// Example Baseline
Page: Homepage (mobile)
LCP: 3.1 seconds
INP: 280 milliseconds
CLS: 0.08
FCP: 2.1 seconds
TBT: 340 milliseconds
Speed Index: 4.2 seconds
Score: 68
Step 2: Set Budgets Based on Thresholds, Not Current Scores
Don't set your budget at your current score. Set it at the "Good" threshold defined by Google. If your current score is below that threshold, your budget becomes your improvement target.
// Budget Configuration
Page: Homepage (mobile)
LCP Budget: ≤ 2.5s (current: 3.1s — OVER BUDGET)
INP Budget: ≤ 200ms (current: 280ms — OVER BUDGET)
CLS Budget: ≤ 0.1 (current: 0.08 — WITHIN BUDGET)
FCP Budget: ≤ 1.8s (current: 2.1s — OVER BUDGET)
TBT Budget: ≤ 200ms (current: 340ms — OVER BUDGET)
Score Budget: ≥ 90 (current: 68 — OVER BUDGET)
Step 3: Prioritize Which Budgets to Enforce
You probably can't fix everything at once. Prioritize:
- LCP — Biggest impact on perceived speed and SEO
- CLS — Often the easiest to fix (HTML/CSS changes)
- INP — Usually requires JS refactoring, which takes longer
- Overall Score — Composite metric that improves as individual metrics improve
Step 4: Enforce Budgets Through Automation
Budgets only work if they're enforced. Options for enforcement:
Monitoring alerts (recommended for most teams):
- Set up automated PageSpeed tests that run daily
- Configure alerts when any metric exceeds its budget
- Review and fix regressions within a defined SLA (e.g., 48 hours)
CI/CD integration (for teams with mature deployment pipelines):
- Run Lighthouse in CI and fail the build if budgets are exceeded
- Block deploys that regress performance metrics
- Require performance review for changes that approach budget limits
Manual review (minimum viable approach):
- Run monthly PageSpeed audits
- Review results against budgets
- Create tickets for budget violations
Step 5: Review and Adjust Quarterly
Performance budgets shouldn't be set once and forgotten. Review them quarterly:
- Tighten budgets when your team consistently meets them (set stretch goals)
- Adjust budgets when requirements change (e.g., new functionality that legitimately impacts performance)
- Add budgets for new pages or new metrics
- Remove budgets that aren't actionable or useful
Performance Budgets for Different Site Types
E-Commerce Sites
| Metric | Budget | Why |
|---|---|---|
| LCP | ≤ 2.0s | Product images are usually the LCP element — optimise aggressively |
| INP | ≤ 150ms | Add-to-cart, filters, and search must feel instant |
| CLS | ≤ 0.05 | Strict — layout shifts on product pages cause misclicks and lost sales |
Content / Blog Sites
| Metric | Budget | Why |
|---|---|---|
| LCP | ≤ 2.5s | Standard threshold; hero images and article bodies are typical LCP |
| INP | ≤ 200ms | Less interactive, so standard threshold is fine |
| CLS | ≤ 0.1 | Watch for ad-related shifts and lazy-loaded images |
SaaS / Web Applications
| Metric | Budget | Why |
|---|---|---|
| LCP | ≤ 2.5s | Dashboard load time matters for user retention |
| INP | ≤ 100ms | App interactions must feel native — strict budget |
| CLS | ≤ 0.05 | Dynamic content loading needs careful layout reservation |
Agency Client Sites (Default Template)
| Metric | Budget (Mobile) | Budget (Desktop) |
|---|---|---|
| LCP | ≤ 2.5s | ≤ 2.0s |
| INP | ≤ 200ms | ≤ 150ms |
| CLS | ≤ 0.1 | ≤ 0.1 |
| FCP | ≤ 1.8s | ≤ 1.5s |
| TBT | ≤ 200ms | ≤ 150ms |
| Score | ≥ 90 | ≥ 90 |
Common Mistakes with Performance Budgets
1. Setting Budgets Too Loose
If your budget is "LCP ≤ 5 seconds", you've set a budget that won't catch real problems. Start at Google's "Good" thresholds. If that's too aggressive for your current state, set a temporary budget at your baseline and work towards "Good".
2. Not Monitoring Both Strategies
Mobile and desktop performance are different. A page might be within budget on desktop but over budget on mobile. Always set and monitor budgets for both strategies.
3. Only Monitoring the Homepage
The homepage is usually the fastest page because it gets the most attention. Monitor landing pages, product pages, blog posts — the pages that actually drive traffic and conversions.
4. Setting Budgets and Forgetting Them
Budgets without enforcement are just numbers in a document. Connect them to alerts and make someone responsible for responding when budgets are exceeded.
5. Treating Budgets as Permanent
As your site evolves, budgets should evolve too. New functionality might justify adjusting a budget. Successful optimisation should lead to tighter budgets.
When to temporarily loosen a budget: During a known incident (e.g. CDN outage, migration) or a planned heavy deployment, you can temporarily relax a budget to avoid alert fatigue. Document the reason and set an expiration date (e.g. "Loosen LCP budget to 3.5s until migration completes on March 15"). Revert to normal as soon as the situation is resolved.
6. Alerting on Natural Variance
Lighthouse scores can fluctuate ±5 points between runs due to network conditions, server load, and test variability. Don't alert on a single test that's 1–2 points below budget. Use cooldowns (e.g. alert only if the metric is over budget for 2+ consecutive tests) or set alert thresholds slightly looser than your budget (e.g. alert at LCP > 2.8s when budget is 2.5s).
Implementing Performance Budgets
Option 1: Monitoring Platform (Easiest)
Use a tool like Apogee Watcher that supports:
- Setting metric-based budgets per site and strategy
- Automated daily testing against budgets
- Alert notifications when budgets are exceeded
- Historical tracking to see budget compliance over time
Option 2: Lighthouse CI
For teams with CI/CD pipelines:
{
"ci": {
"assert": {
"assertions": {
"categories:performance": ["error", { "minScore": 0.9 }],
"largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
"total-blocking-time": ["error", { "maxNumericValue": 200 }],
"cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }]
}
}
}
}
Option 3: Spreadsheet Tracking (Manual)
If you're just starting out, even a spreadsheet works. Track scores weekly, colour-code cells (green = within budget, red = over budget), and review during team standups.
Key Takeaway
Performance budgets turn vague performance goals into concrete, enforceable constraints. They prevent gradual degradation, create accountability, and give your team a clear definition of "fast enough."
Start with metric-based budgets at Google's "Good" thresholds. Enforce them through automated monitoring and alerts. Review and tighten quarterly. That's it.
FAQ
What's the difference between a performance budget and a performance goal?
A goal is aspirational ("we'd like to be fast"); a budget is a hard constraint ("we will not exceed 2.5s LCP"). Budgets trigger action when exceeded; goals don't. Budgets enable automation (alerts, CI gates); goals are subjective.
Should I set different budgets for mobile vs desktop?
Yes. Mobile typically lags desktop due to slower networks and devices. Use separate mobile and desktop budgets — for example, LCP ≤ 2.5s mobile and ≤ 2.0s desktop. Many monitoring tools let you configure per-strategy thresholds.
How do I choose thresholds for a site that's currently slow?
Start with your current baseline as the initial budget. That prevents further degradation. Then set stretch goals (Google's "Good" thresholds) and tighten the budget as you fix issues. Don't set an unrealistic budget you'll immediately violate.
Can performance budgets block deployments?
Yes. Lighthouse CI and similar tools can fail CI/CD when budgets are exceeded. For monitoring platforms, budgets typically trigger alerts instead of blocking. Choose alerts for flexibility; use CI gates when you want zero tolerance for regressions.
Want to set and enforce performance budgets across all your sites? Apogee Watcher makes budget management part of automated monitoring. Join the waitlist for early access.
Top comments (0)