Your first performance budget

6 July 2026

Websites rarely get slow in one dramatic moment. They get slow the way a junk drawer fills up. One more script, one more hero image, another embed. Each addition is defensible on its own, and none of them is noticeable on its own. Eighteen months later the site takes six seconds to load and nobody can point to the release that did it, because no single release did.

A performance budget is the defence against this. It is a set of limits you agree on in advance, so that a bit slower stops being free. Nothing fancy, just a short list of numbers with a line drawn under them. For example:

• Largest Contentful Paint (LCP) under 2.5 s on a mid-range phone.
• Total page weight under 1.5 MB; JavaScript under 300 KB.
• Cumulative Layout Shift under 0.1.
• No more than 5 third-party domains contacted per page.

The specific numbers matter less than the fact that they are written down and agreed before the work, not negotiated after it. A budget turns an argument about taste (it feels fine to me) into a check against a number everyone already signed up to.

How to pick numbers you'll actually keep

The classic mistake is copying ideal numbers from a conference talk, failing them on day one, and abandoning the budget by week three. Do it in this order instead:

1. Start from your baseline. Measure where you actually are today, across the whole site rather than just the homepage. (The baseline report exists for this.) If your p75 LCP is 4.8 s, then your first budget is nothing gets worse than today. A ratchet, not a wish.
2. Aim at the real thresholds. As you improve, move the budget toward the levels visitors and search engines actually judge you by, the Core Web Vitals thresholds of LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 at the 75th percentile.
3. Look at your competitors. A budget of faster than the three sites our customers compare us against is easier to defend in a leadership meeting than any abstract number. Competitor benchmarking gives you those numbers instead of guesses.
4. Budget the causes, not just the outcomes. LCP is an outcome; page weight, script size and third-party count are causes you can review in a pull request. Put both kinds in the budget. Outcomes give you the goal, causes give you the daily discipline.

A budget nobody checks is a poster

The budget itself does nothing. Its value sits entirely in the moment when someone, or something, says this change breaks it.

Relying on people to remember to check is how budgets die. The setup that survives contact with a real release schedule is automated:

• Test the change before it ships. If you have a staging or UAT environment, test there. A budget violation caught before production is a code review comment. Caught after, it's an incident. (This is the workflow the Standard tier is built around, including static-IP testing to reach environments behind a firewall.)
• Let a webhook deliver the bad news. When a test run finishes, a webhook can post to your team chat, flag the release, or open a ticket automatically the moment a page crosses its budget. The loop closes without anyone having to remember anything. The change ships, the test runs, you're told, you act.

Expect the budget to be tested by humans, too. Sooner or later, someone will want an exception. The campaign page really does need the video embed, or the new tool really does need its script. Good. That's the budget working. A budget doesn't forbid the cost, but it does make the cost visible and deliberate. To add this, we drop that, or we raise the budget on purpose and write down why.

The junk drawer never gets that conversation. Your website should.

The Standard tier measures your baseline and watches the budget for you, with webhooks when a page crosses it. See the plans.