Performance budgets that actually hold

Teams run an optimisation project, metrics improve, and six months later they are back where they started. Nothing was done wrong — a dependency here, an analytics script there, an image that skipped optimisation. Each change is individually defensible.

Without an automated gate, performance decays by default. The fix is not more discipline; it is making the regression visible at the moment it is introduced.

Budget the metrics that reflect experience — Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift — and support them with a JavaScript transfer budget, since script size is the usual root cause.

Measure on a throttled mid-range mobile profile rather than a developer laptop. The gap between the two is where most performance problems hide.

Run Lighthouse CI against preview deployments and fail the build when a budget is exceeded. A warning that appears in a log nobody reads changes nothing; a failing check starts a conversation.

Allow explicit, documented exceptions. A team that cannot override a budget when there is a genuine reason will eventually disable the check entirely.

Lab measurements catch regressions; field data tells you what customers actually experience. Collect real user metrics segmented by device class and connection, and treat the 75th percentile as the number that matters.

When lab and field disagree, the field is right. Usually it means your test profile is more generous than the devices your customers use.