Every kickoff call includes the same sentence: performance matters to us. We have never once heard a client say the opposite. And yet the majority of sites we audit before taking over a rebuild are carrying four megabytes of JavaScript to render a page that could load in under one second.

The gap between the stated value and the shipped result is not a competence problem. It is the absence of a number that anyone is actually accountable to.

What a performance budget actually is

A performance budget is a hard ceiling, on page weight, on JavaScript execution time, on Largest Contentful Paint, that a feature is not allowed to cross regardless of how valuable it seems in isolation. It converts “performance matters” from a sentiment into a constraint that shows up in code review, the same way a type error or a failing test does.

Without a number, performance degrades by a thousand reasonable-sounding decisions. One more tracking script here. One more carousel library there. Each individually defensible. Collectively, a page that takes four seconds to become interactive on a mid-range phone.

The number we hold ourselves to

  • Largest Contentful Paint under 2.0 seconds on a throttled mobile connection
  • Total JavaScript payload under 170KB compressed, per route
  • Zero layout shift after initial paint: Cumulative Layout Shift held at 0
  • Time to Interactive under 3.0 seconds on the same throttled profile

These are not aspirational. They are enforced. A feature that would break the budget does not ship as proposed. It ships in a lighter form, or it ships after something else is removed to make room for it.

A performance budget only works if it can say no to something the client wants. If it never blocks a feature, it is not a budget. It is a suggestion.

How performance quietly erodes

No one sets out to build a slow site. It happens through accumulation: a font loading strategy nobody revisits, a third-party chat widget added after launch, an image pipeline that was fine at ten product photos and never revisited at four hundred. Each addition passes review individually. None of them are reviewed against a budget, because there isn’t one.

Eighteen months later, the business is paying an agency to diagnose why conversion has dropped, when the actual cause is sitting in the network tab the whole time.

Enforcing it without slowing delivery

The objection we hear most is that performance budgets slow teams down. In our experience it is the opposite: a budget checked automatically in CI catches a regression in minutes, before it ships, rather than three months later when a client asks why the site feels sluggish and nobody can point to a single cause.

We run budget checks the same way we run tests, on every pull request, blocking merge if the numbers regress past the threshold. It costs a few seconds of build time. It saves weeks of retroactive diagnosis.

What a slow site actually costs

The data on this is not new, but it bears repeating because so few teams act on it: every additional second of load time on mobile measurably reduces conversion, and the drop-off is steepest in the first three seconds, which is exactly where most sites we inherit are losing visitors before a single word has been read.

A slow site is not a technical debt. It is a tax on every visitor who arrives, paid whether or not the business ever notices it is being charged.

We enforce a performance budget on every engagement, not because it is fashionable, but because it is the only mechanism we have found that reliably converts a stated value into a shipped outcome.

Say performance matters all you want. We would rather show you the number.