Performance Budgets: Setting Speed Standards for Every Project

You wouldn’t launch a product without a financial budget. You wouldn’t start a construction project without a timeline. So why do most web projects launch without any performance budget at all?

A performance budget is a set of measurable limits for metrics that affect your site’s user experience: things like page weight, load time, and Core Web Vitals scores. It’s a line in the sand that says “this website will load in under X seconds” and “our total JavaScript payload will not exceed Y kilobytes.” For the full walkthrough, start with the website performance checklist we work through on every build.

Without a performance budget, performance degrades gradually. A new font here. An extra plugin there. A larger hero image. A third-party chat widget. Each addition seems small, but they accumulate. Six months after launch, the site that loaded in 1.5 seconds now takes 4.5 seconds, and nobody can pinpoint when it got slow because no individual change seemed significant.

We set performance budgets for every project we build. They keep us honest during development, prevent gradual degradation after launch, and give our clients a measurable standard for their website’s speed. Here’s how we do it, and how you can implement the same approach.

What Goes Into a Performance Budget

A performance budget typically includes three categories of metrics.

Quantity-Based Metrics

These are the raw numbers, the weight and count of assets your page delivers:

• Total page weight: the combined size of all assets (HTML, CSS, JavaScript, images, fonts, etc.) measured in kilobytes
• JavaScript weight: total JavaScript payload, compressed
• CSS weight: total CSS payload, compressed
• Image weight: total image payload per page
• Font weight: total custom font payload
• Number of HTTP requests: total requests the page makes
• Third-party request count: requests to external domains

Timing-Based Metrics

These measure how fast the page actually loads and becomes usable:

• Largest Contentful Paint (LCP): when the main content finishes rendering. Target: under 2.5 seconds.
• Interaction to Next Paint (INP): how quickly the page responds to user interactions. Target: under 200 milliseconds.
• Cumulative Layout Shift (CLS): how much the page layout shifts during loading. Target: under 0.1.
• Time to First Byte (TTFB): how quickly the server responds. Target: under 800 milliseconds.
• First Contentful Paint (FCP): when the first piece of content appears. Target: under 1.8 seconds.
• Total Blocking Time (TBT): how long the main thread is blocked. Target: under 200 milliseconds.

Rule-Based Metrics

These are scores from testing tools:

• Lighthouse Performance Score, target: 90+ on both mobile and desktop
• PageSpeed Insights score, target: 90+ (uses real-world data from Chrome User Experience Report)
• WebPageTest Speed Index, target: under 3.0 seconds

Setting Realistic Targets

Performance budgets need to be ambitious enough to ensure a good user experience but realistic enough to be achievable. Here’s how we set targets.

Start with Core Web Vitals

Google’s Core Web Vitals are the non-negotiable baseline. These directly affect search rankings:

Your performance budget should target the “Good” threshold for all three metrics. That’s the minimum. We typically aim below these thresholds to provide margin.

Benchmark Against Competitors

Look at how your competitors’ sites perform. If the top three competitors in your market have LCP scores of 3.5, 4.2, and 5.1 seconds, an LCP target of 2.0 seconds gives you a significant competitive advantage.

Run competitor sites through PageSpeed Insights and WebPageTest. Document their scores. Then set your targets to beat them.

Consider Your Audience

Your target audience affects how aggressive your budget should be:

Our Default Performance Budgets

For a typical small business website, here are our default starting budgets:

Quantity Budgets:

• Total page weight: 500KB or less (compressed)
• JavaScript: 50KB or less (compressed)
• CSS: 30KB or less (compressed)
• Images: 300KB or less per page (after responsive image optimization)
• Fonts: 100KB or less
• HTTP requests: 25 or fewer
• Third-party requests: 5 or fewer

Timing Budgets (Mobile, 4G):

• LCP: under 2.0 seconds
• INP: under 100 milliseconds
• CLS: under 0.05
• FCP: under 1.5 seconds
• TBT: under 150 milliseconds
• TTFB: under 600 milliseconds

Score Budgets:

• Lighthouse mobile: 90+
• Lighthouse desktop: 95+

These are achievable for a well-built small business website. They’re tight enough to ensure a genuinely fast experience and loose enough to allow for necessary functionality.

For web applications (dashboards, tools, interactive features), we adjust the JavaScript budget upward but maintain the timing budgets through code splitting and lazy loading.

Enforcing Budgets During Development

A performance budget that isn’t enforced is just a wish. Here’s how we make budgets part of the development workflow.

Automated Budget Checking in CI/CD

We integrate performance budget checking into our continuous integration pipeline. Every pull request gets checked against the performance budget before it can be merged.

Lighthouse CI is our primary tool for this:

# lighthouserc.js
module.exports = {
  ci: {
    assert: {
      assertions: {
        'categories:performance': ['error', { minScore: 0.9 }],
        'largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
        'interactive': ['error', { maxNumericValue: 3500 }],
        'cumulative-layout-shift': ['error', { maxNumericValue: 0.1 }],
        'total-byte-weight': ['error', { maxNumericValue: 500000 }],
        'resource-summary:script:size': ['warn', { maxNumericValue: 50000 }],
        'resource-summary:stylesheet:size': ['warn', { maxNumericValue: 30000 }]
      }
    }
  }
};

If a developer’s changes push the site over any budget threshold, the build fails. They see exactly which budget was exceeded and by how much. The fix happens before the code ships, not after.

Bundle Size Monitoring

For JavaScript-heavy projects, we use bundlesize or size-limit to check bundle sizes on every commit:

// package.json
{
  "size-limit": [
    { "path": "dist/main.js", "limit": "50 KB" },
    { "path": "dist/vendor.js", "limit": "100 KB" },
    { "path": "dist/main.css", "limit": "30 KB" }
  ]
}

This catches the most common source of performance regression: someone adds a new dependency or feature that significantly increases bundle size.

Real-Time Performance Monitoring

After launch, performance budgets need ongoing monitoring. We use:

• Google Search Console Core Web Vitals report: shows real-user data for your site, flagging any URLs that fall into “Needs Improvement” or “Poor” categories
• SpeedCurve: continuous synthetic monitoring that tracks performance over time and alerts when budgets are exceeded
• Web Vitals JavaScript library: embedded in the site to report real-user performance data to your analytics platform

Browser DevTools Performance Panel

During development, Chrome’s Performance panel and the Lighthouse tab are the fastest way to check whether a change affects performance. We check Lighthouse before and after significant changes to catch regressions early.

What Happens When You Exceed a Budget

Exceeding a performance budget isn’t a crisis. It’s a decision point. Here’s the process:

1. Identify the Cause

What changed? A new image? A third-party script? A new feature with additional JavaScript? The CI/CD pipeline should tell you exactly which metric was exceeded.

2. Evaluate the Trade-Off

Is the new addition worth the performance cost? Sometimes yes:

• A critical business feature that requires additional JavaScript
• A third-party integration that provides significant value
• Richer content that improves the user experience

Sometimes no:

• A “nice to have” animation library
• A plugin that does something achievable with less code
• An unnecessarily large image that could be optimized

3. Decide and Document

If you decide the addition is worth the budget impact:

• Adjust the budget with a documented reason
• Look for savings elsewhere to offset the increase
• Set a flag to revisit and optimize later

If you decide it’s not worth it:

• Find a lighter alternative
• Optimize the implementation
• Defer it to a future phase

4. Avoid Budget Inflation

The biggest risk with performance budgets is gradual inflation. Each exception seems reasonable in isolation, but after ten exceptions, the budget has doubled. Review the total budget quarterly and resist the temptation to continuously loosen targets.

Team Accountability

Performance isn’t just a developer concern. Everyone involved in a web project affects performance:

Designers

• Image-heavy designs mean heavier pages
• Custom fonts add weight
• Complex animations require JavaScript
• Layout complexity can affect CLS

Budget impact: We share the image and font budgets with designers upfront. “You have 300KB for images and 100KB for fonts on this page. Design within those limits.”

Content Creators

• Unoptimized images uploaded to the CMS
• Embedded videos (especially auto-playing ones)
• Third-party embeds (social media feeds, maps, etc.)

Budget impact: We configure the CMS to automatically optimize uploaded images and educate content creators on the performance impact of embeds.

Marketing Team

• Adding tracking scripts and pixels
• Installing chat widgets and pop-ups
• A/B testing tools that inject JavaScript
• Social proof widgets and popups

Budget impact: Every third-party script request goes through a performance review. We measure the script’s impact before approving it.

Stakeholders

• “Can we add a video background?”
• “Can we integrate this third-party widget?”
• “Can we add more animations?”

Budget impact: We frame these conversations around trade-offs. “Adding this video background will push our LCP from 1.8 seconds to 3.2 seconds. Here’s how that affects our search rankings and conversion rate. Still want to proceed?”

The Business Case for Performance Budgets

Performance budgets aren’t just a technical exercise. They have direct business impact.

Conversion Rate Impact

Study after study shows the relationship between load time and conversion:

• A one-second delay in page load reduces conversions by 7% on average
• Pages that load in under two seconds have 15% higher conversion rates than those loading in five seconds
• Mobile users are 50% more likely to abandon a page that takes longer than three seconds

For a site generating $50,000/month in revenue, a one-second improvement in load time could mean an additional $3,500/month.

SEO Impact

Core Web Vitals are a ranking factor. Sites that meet the “Good” threshold for all three metrics have a measurable advantage over sites that don’t. For local businesses competing in a geographic area, this edge can mean the difference between showing up on the first page and being buried.

Cost Reduction

Faster sites use less bandwidth (lower hosting costs), require fewer server resources (fewer infrastructure upgrades), and reduce support requests (fewer “is your site down?” calls from customers on slow connections).

Getting Started with Performance Budgets

If you don’t currently have a performance budget, here’s how to start:

1. Baseline your current performance. Run your site through PageSpeed Insights and Lighthouse. Document your current scores and metrics.
2. Set targets. Use the Core Web Vitals “Good” thresholds as your minimum. Aim for better if your current performance allows it.
3. Integrate monitoring. Set up at least one automated monitoring tool (Google Search Console is free and reports real-user data).
4. Add CI checks. If you have a build process, add Lighthouse CI or a bundle size checker.
5. Review monthly. Check your performance metrics alongside your business metrics. Look for correlation between performance improvements and business outcomes.

Keep Reading

• The ROI of Local SEO: Tracking Real Revenue from Organic Search
• Deploying Web Applications: CI/CD Pipelines for Small Teams
• The Ultimate Performance Checklist: Launching Fast Websites Every Time