Setting performance budgets that survive the next redesign

We have a slightly uncomfortable statistic from our own work: when we revisit sites a year after a speed project, most have given back a good part of the gains. Nobody decided to make the site slower. A new hero video was added, then a personalization script, then a font weight for a campaign, and each change looked harmless on its own. Performance budgets exist to make those trade-offs visible at the moment they are made. Done well, they are less about saying no and more about making sure someone knowingly says yes.

Choose metrics people can act on

A budget is only useful if a developer or designer can see how their change affects it. We use a mix of three kinds of metric.

• User-centric outcomes: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, measured in the field. These are what customers feel and what search engines see.
• Lab proxies: LCP and Total Blocking Time from a controlled Lighthouse run. They are noisy, but they can run on every pull request.
• Resource quantities: JavaScript bytes, image bytes on the initial viewport, number of third-party requests and web font files. These are the easiest to understand and the hardest to argue with.

Resource budgets are underrated. A developer cannot easily reason about how a change affects LCP at the 75th percentile, but they can see instantly that their pull request adds 90 KB of compressed JavaScript to the product page.

Set thresholds from where you are, not from a blog post

Budgets copied from generic guidance tend to be either impossible or meaningless. We set them from the site's own data in three steps.

1. Baseline. Record current field metrics by template from CrUX or RUM, and current resource sizes from a crawl of representative pages.
2. Target. Set targets for the metrics that fail today, usually the Core Web Vitals good thresholds: LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1 at the 75th percentile.
3. Ceiling. For resource budgets, set a ceiling at roughly the current value after optimization plus a small margin, typically 5 to 10 percent, so ordinary changes fit but a new heavy dependency does not.

Budgets are per template. A homepage with a large hero and a checkout step have completely different needs, and a single sitewide number punishes one while ignoring the other.

A budget nobody can fail is a wish. A budget everyone fails is noise. The useful ones fail occasionally, and loudly.

Enforce it in CI

A budget in a slide deck will not survive a redesign. A budget that blocks a merge will. Our standard setup runs on every pull request against a preview deployment:

• Lighthouse CI runs three times per key template and uses the median, which reduces noise considerably.
• Resource budgets are declared in a budget file and checked against the build output and the rendered page.
• The results are posted as a comment on the pull request, with a clear pass or fail and the size of the change.

[
  {
    "path": "/products/*",
    "resourceSizes": [
      { "resourceType": "script", "budget": 180 },
      { "resourceType": "image", "budget": 450 },
      { "resourceType": "font", "budget": 90 }
    ],
    "resourceCounts": [
      { "resourceType": "third-party", "budget": 12 }
    ]
  }
]

We make failures blocking for resource budgets and warnings for lab timings, because timing noise would otherwise train the team to ignore the check. When a budget must be exceeded for a good reason, the pull request needs an explicit override and a note explaining the trade-off. That record is valuable six months later when someone asks why the page got heavier.

Test environments matter here too. Lab runs on a shared CI runner vary with whatever else the machine is doing, so we run Lighthouse on dedicated runners with fixed CPU throttling, against a preview deployment that uses production-like caching and a CDN. Measuring a development server without compression or caching produces numbers that are both slower and less stable than reality, and the team quickly learns to distrust them.

Budgets for things CI cannot see

Many regressions never pass through a pull request. Marketing teams add tags through a tag manager, content editors upload 4 MB images, and apps inject scripts from their own servers. For these we add two safeguards. First, scheduled synthetic tests run daily against production and alert when a template exceeds its budget. Second, real user monitoring tracks field metrics by template and alerts when a 7-day rolling 75th percentile crosses a threshold. Between them, these catch most regressions within days rather than when Search Console flags them a month later.

We also give content and marketing teams guardrails of their own, such as automatic image compression on upload and a short approval process for new third-party tags. Most people are happy to respect a budget once they can see it.

Getting buy-in from the people who pay for the site

Budgets work when stakeholders understand what they protect. We tie them to business metrics wherever the data allows: conversion rate by LCP bucket, bounce rate by device, organic landing page performance. When a stakeholder can see that sessions with a fast LCP convert noticeably better than slow ones on their own site, the budget stops being an engineering preference and becomes a revenue protection policy.

We set up budgets as part of our Core Web Vitals optimization and site speed optimization projects, and the CI integration is usually built alongside our CI/CD pipelines work so budgets run in the same place as tests.

Protect the speed you paid for

If you have invested in performance and want to keep it, we can set up budgets, CI checks and monitoring tailored to your templates. Get in touch for a fixed-price quote, delivered within 24 hours.