Performance Budgets: Keeping Your Website Fast

Websites start fast and get slower. Features accumulate, images creep larger, scripts multiply. Without conscious effort, the 2-second load time at launch becomes 8 seconds a year later. Performance budgets prevent this decay by defining limits and enforcing them.

What Is a Performance Budget?

A performance budget sets concrete limits on metrics that affect user experience:

Maximum page weight (total kilobytes)
Maximum JavaScript bundle size
Number of requests
Core Web Vitals thresholds
Time-based metrics (LCP, Time to Interactive)

Like a financial budget, a performance budget forces tradeoffs. Want to add a new feature? Something else might need to shrink. Want a larger hero image? Compress it more aggressively or remove something else.

Why Budgets Matter

Preventing Decay

Without limits, each addition seems harmless. A new tracking pixel here, a fancier slider there, a marketing video, an analytics tool. Each adds weight. Collectively, they devastate performance.

Budgets make this visible. Adding a 200KB script to a page with a 500KB JavaScript budget triggers a conversation before deployment, not after users complain.

Creating Accountability

When performance is "someone else's problem," nobody owns it. Budgets create shared responsibility. Marketing can't add unlimited pixels. Developers can't ignore bundle size. Everyone has skin in the game.

Focusing Decisions

Budgets clarify priorities. If you're at your JavaScript limit, you must choose: is this new library worth more than something you already have? Does this feature justify its cost? Often, the answer is no—and the budget prevents a regrettable decision.

Setting Realistic Budgets

Baseline from Current State

If your site exists, measure current performance. Budgets shouldn't be aspirational fantasies—they should be achievable targets. If your page currently weighs 3MB, a 300KB budget isn't realistic without major rebuilding.

Competitor Analysis

How fast are competitors? You probably need to match or beat them. If they load in 2 seconds and you load in 6, users notice. Set budgets that achieve competitive performance.

User Context

Consider your audience's devices and connections:

Mobile-heavy audience? Budget for slower connections
Global audience? Consider international connection speeds
Enterprise B2B? Users might have fast office connections

Testing on throttled connections reveals what real users experience.

Core Web Vitals Targets

Google's Core Web Vitals provide clear targets:

LCP (Largest Contentful Paint): Under 2.5 seconds
CLS (Cumulative Layout Shift): Under 0.1
FID/INP (First Input Delay/Interaction to Next Paint): Under 100/200ms

These are meaningful thresholds with real consequences for search ranking and user experience.

What to Budget

Page Weight

Total kilobytes transferred. For most sites, staying under 1-2MB is reasonable. Under 500KB is excellent. Over 5MB is problematic on mobile connections.

JavaScript

JavaScript affects both download and parsing time. Large JavaScript bundles delay interactivity even after downloading. Many sites could budget 100-300KB of JavaScript total.

Images

Often the largest component. Budget the hero image specifically—it's usually the LCP element. Perhaps 200KB maximum for above-the-fold images.

Third-Party Scripts

Analytics, tracking, chat widgets, marketing tools—these add up quickly and are often outside developer control. Establishing a third-party budget forces evaluation of each tool's value.

Time-Based Metrics

Sometimes a time budget is more meaningful than bytes:

Time to first byte: under 200ms
LCP: under 2.5 seconds
Time to Interactive: under 3 seconds

Enforcing Budgets

Budgets without enforcement are wishes, not budgets.

Build-Time Checks

Integrate budget checks into your build process. If the JavaScript bundle exceeds the budget, the build fails. Tools like bundlesize, Lighthouse CI, and various webpack plugins enable this.

# Example: Bundle size check fails if main.js exceeds 200KB
bundlesize --files 'build/main.js:200KB'

Pull Request Checks

Services like Lighthouse CI can run performance tests on every pull request, comparing against budgets and blocking merges that exceed limits.

Monitoring

Real User Monitoring (RUM) tracks actual performance over time. Alerts when performance degrades beyond thresholds. SpeedCurve, Calibre, and similar tools provide this.

Regular Audits

Even with automated checks, periodic manual audits catch issues automated tools miss. Review third-party scripts, check for newly added resources, verify images remain optimised.

When Budgets Are Exceeded

When something would break the budget, you have options:

Don't add it: Is this feature worth the cost? Maybe not.
Optimise it: Can the new thing be smaller? Can existing things be optimised to make room?
Remove something else: Trade-offs. What's less valuable than the new thing?
Adjust the budget: If genuinely necessary and justified, budgets can change—but consciously, not by accident.

The value of budgets is forcing these conversations before deployment rather than noticing poor performance later.

Budget Examples

Sample budget for a business website:

Metric	Budget
Total page weight	1.5 MB
JavaScript	200 KB
Images (above fold)	200 KB
Third-party scripts	150 KB
LCP	2.0 seconds
CLS	0.05

Adjust based on your context—eCommerce sites with many product images might need different limits than content sites.

Getting Started

Measure current performance across key pages
Research competitor performance
Define realistic but challenging budgets
Document budgets and share with the team
Implement automated checking where possible
Review regularly and adjust as needed

Our Approach

We consider performance from project start, not as an afterthought. We help clients set appropriate budgets, implement enforcement, and maintain performance over time through our care plans.

If your site has slowed over time or you want to prevent performance decay, contact us to discuss how performance budgets and monitoring could help.