Why Every Product Team Needs a Performance Budget

Conversion rate tends to fall off sharply as load time climbs from around one second to around five — and most of that drop happens well before five seconds arrives. Speed isn't a UX nicety anymore. It's a number on the same page as revenue, and it's usually one of the cheapest levers a team has to move that number.

The Cost of Slow, in Real Numbers

The relationship between speed and money is unusually well documented for something so often deprioritized:

• Every additional 100 milliseconds of load time has been associated with roughly a 1% drop in conversion.
• A large share of mobile visits are abandoned once load time crosses about three seconds.
• A one-second delay has been linked to around a 7% drop in conversions and a meaningful rise in bounce rate.
• Real companies that invested in Core Web Vitals work have reported double-digit gains in both conversion and revenue per visitor after the fact.

Mobile is where this bites hardest. Fewer than half of mobile sites currently pass all three Core Web Vitals thresholds, while desktop pass rates are meaningfully higher — and mobile now accounts for the majority of e-commerce traffic. The gap between mobile and desktop performance is, in a lot of businesses, a gap in revenue nobody has actually sized.

Why Most Teams Still Don't Track This

Performance rarely breaks all at once. It erodes — one added dependency, one unoptimized image, one extra script from a marketing tag manager at a time. No single pull request looks like the one that caused the regression, which is exactly why it survives code review. Catching this requires the same instinct as catching an accessibility regression: nobody notices decline from a manual read-through, because no single change looks big enough to flag.

What a Performance Budget Actually Looks Like

A performance budget is deliberately narrow. It isn't a performance strategy document — it's a small set of numbers a build either meets or doesn't:

• Pick two or three metrics that map to what users actually feel — typically Largest Contentful Paint, interaction responsiveness, and total JavaScript shipped to the browser.
• Set a hard numeric ceiling for each, based on your current baseline and where you actually need to be, not an arbitrary industry benchmark.
• Check every pull request against that ceiling automatically, before merge — not in a quarterly performance audit.

Making It Stick

Budgets fail the moment they become aspirational rather than enforced. If exceeding the budget produces a Slack message someone can dismiss, it will get dismissed, repeatedly, until the budget is meaningless. If it fails the build the same way a broken test does, engineers treat it the way they treat a broken test — as something to fix before merging, not something to circle back to later.

None of this requires a performance team or a quarter-long initiative. It requires picking two numbers that matter, wiring a check into CI, and refusing to let it become optional. That's a smaller project than most teams assume, and it's one of the few engineering investments with a conversion-rate number attached to it on day one.