Why fast sites get slow
No website slows down overnight. It gains weight one reasonable-sounding decision at a time: a marketing tag added for a campaign nobody switched off, a hero video the brand team loved, a fourth font weight, a chat widget, a plugin that seemed harmless. HTTP Archive data shows median page weight creeping upward year after year across the web, and small-business sites are no exception. Six months after a fast launch, the numbers have quietly doubled.
A performance budget is the antidote: an agreed set of limits, written down, that every change to the site must respect. It turns "the site feels slow" arguments into a measurable pass or fail.
Choose metrics worth budgeting
Budget two kinds of numbers: outcomes users feel, and quantities you can control directly.
Outcome metrics
Google's Core Web Vitals are the sensible baseline because they are measured on real users and feed into search rankings: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint within 200 milliseconds, and Cumulative Layout Shift below 0.1.
Quantity metrics
- Total page weight (compressed) per template.
- JavaScript weight, budgeted separately, because a kilobyte of JavaScript costs far more processing time on a phone than a kilobyte of image.
- Number of requests and number of third-party scripts.
- Web font count and combined font file size.
Quantity metrics matter because your team can check them before launch. You do not need to wait a month for field data to know a 4 MB page will fail.
Need a hand with this?
Our team delivers Web Design for UK businesses — with a free initial consultation, transparent fixed quotes and no lock-in contracts. Tell us what you're working on →
Set numbers you can defend
Baseline first: run your key templates through PageSpeed Insights and note both the lab results and, if you have enough traffic, the Chrome UX Report field data. Then benchmark two or three competitors. A practical approach is to set each limit at whichever is stricter: your current figure, or comfortably better than your best competitor. A long-standing rule of thumb holds that users only notice a speed change of around twenty per cent, so meaningful budgets need real headroom, not token trims.
An example starting budget for a small-business marketing site:
- Total page weight: 1.5 MB or less per template.
- JavaScript: 300 KB compressed or less.
- LCP under 2.5 seconds on a mid-range Android over 4G, not just on office fibre.
- No more than two font families, subsetted, and no more than five third-party scripts.
Adjust for your context. The exact numbers matter less than the fact that they are written down and agreed by everyone who can add things to the site.
Enforce it automatically, not by memory
Budgets kept in someone's head die within a quarter. Wire them into tooling instead:
- Lighthouse CI accepts a budget.json file and fails a build when a page exceeds its limits, which is ideal if your site deploys through GitHub or a similar pipeline.
- size-limit or bundlewatch guard JavaScript bundle sizes on every pull request.
- SpeedCurve, Calibre or DebugBear monitor live pages continuously and alert when a budget is breached, which suits WordPress sites with no build pipeline.
- At minimum, a recurring calendar slot with PageSpeed Insights and a spreadsheet is infinitely better than nothing.
When a change breaches the budget there are exactly three honest responses: optimise the change, remove something else of equal weight, or consciously agree a new budget. The forbidden fourth option is shipping anyway and hoping.
Govern the humans, not just the code
Most page weight arrives through decisions, not code, so a little process prevents most of it:
- Every third-party tag gets a named owner and a review date; unowned tags are removed at a quarterly audit.
- Design reviews include an estimated weight for new sections, especially video, carousels and animation libraries.
- On WordPress, trial new plugins on staging and check their front-end payload before approving them.
- Report the budget monthly in whatever meeting reviews marketing numbers, so speed stays visible alongside traffic and leads.
This sounds bureaucratic and takes perhaps an hour a month. It is far less painful than the emergency optimisation project that otherwise arrives every eighteen months.
Key Takeaway
Write your performance budget down and wire it into your workflow. Pick a handful of limits, such as total page weight, JavaScript size and the Core Web Vitals thresholds of 2.5 seconds LCP, 200 ms INP and 0.1 CLS, then enforce them with Lighthouse CI or a monitoring tool that alerts on regressions. When a change busts the budget there are only three honest options: optimise it, remove something else, or consciously agree a new budget. Never let it fail silently.
Redesigns: where budgets go to die
The most dangerous moment for performance is a redesign, because everything is renegotiated at once and excitement outranks discipline. Put the budget in the design brief and the development contract before creative work starts, and make passing it a condition of sign-off. It is far cheaper to design within a budget than to optimise a heavy design after the fact, and "the new site is slower than the old one" is a conversation nobody enjoys.
Held to consistently, a performance budget is how a site stays fast for years rather than months. If you want help setting a realistic budget or building the monitoring around it, our team can set that up alongside your existing site.