Setting a Website Performance Budget That Actually Means Something

A performance budget is a set of numbers agreed before anyone touches the site, not a reaction gathered afterwards from someone saying it "feels slow." Without one, every performance conversation defaults to opinion: the owner thinks it is slow, the developer thinks it is fine, and nobody can settle it because nobody wrote down what "fine" means. A budget fixes that — it names the metrics that matter, sets a target for each, and gives everyone the same yardstick.

What to actually measure

Google's Core Web Vitals are the closest thing to an industry-standard starting point, because they are the metrics Google itself uses as a ranking signal and publishes real thresholds for, measured at the 75th percentile of real visits — meaning at least three in four visitors need to be inside the "good" range for a page to pass overall.

These thresholds come directly from web.dev, Google's own performance documentation: LCP (web.dev/articles/lcp), INP (web.dev/articles/inp), and CLS (web.dev/articles/cls). A realistic budget for most business sites is simply to sit inside "good" on all three, measured on the pages that actually carry traffic — the homepage and whatever lands visitors from search or ads — rather than chasing a perfect score on a page nobody visits.

TTFB is a diagnostic, not a target in itself

Time to First Byte — how long the server takes to send the first byte of a response — gets treated as a fourth Core Web Vital by a lot of performance tooling and a lot of agencies. It is not one. Google's own article on the metric is explicit that TTFB is not among the Core Web Vitals, but it matters anyway because web.dev calls it "a foundational metric for measuring connection setup time and web server responsiveness", which is what everything downstream depends on: a slow TTFB puts a floor under how fast LCP can ever be, no matter what else is optimised on the page (web.dev/articles/ttfb).

The practical implication: do not put TTFB in the budget as a pass/fail line on its own. Use it as a diagnostic when LCP is failing — if TTFB is high, the bottleneck is server response time (hosting, database queries, an uncached page), and no amount of image compression or script trimming on the front end will fix it. If TTFB is fine but LCP still fails, the problem is downstream of the server, in what loads and renders after the first byte arrives.

Images: the budget line that gets blown first

On most content-heavy business sites, images are the single largest contributor to page weight, and they are usually the fastest budget item to fix because the fix does not touch layout, code, or third-party integrations. Three things do most of the work:

• Format. Modern formats (WebP, or AVIF where supported) produce noticeably smaller files than JPEG or PNG at equivalent visual quality, and most current browsers support both.
• Sizing. An image should be served at roughly the dimensions it displays at, not a 4000-pixel-wide photo scaled down by CSS to fit a 600-pixel card. The browser still downloads the full file either way.
• Loading strategy. Everything below the first screen should be lazy-loaded so it does not compete with the content a visitor actually sees first; the one image that does appear first — usually the hero image driving LCP — should be the opposite: prioritised to load immediately, not lazy-loaded.

None of this requires exotic tooling. It requires deciding it is a standing rule for anyone adding content to the site, because a performance budget that only holds until the next blog post uploads an unresized photo straight from a phone is not really a budget.

Third-party scripts: the usual real culprit

When a site that was fast at launch gets slower over time without anyone changing the core code, the cause is very often accumulation: an analytics tag, a chat widget, a marketing pixel, an A/B testing script, a font loaded from an external service, each added independently for a reasonable business reason, none of them reviewed together. Each one is a separate network request, and often a separate piece of JavaScript competing for the same main thread that has to respond to a visitor's click — which is exactly what INP measures.

The fix is not necessarily removing all of it — a chat widget or an analytics tag can be a legitimate business requirement. It is auditing what is actually loaded on the pages that matter, checking whether each script is still in use, and loading anything non-essential asynchronously or deferring it until after the main content has rendered, so a marketing pixel is not blocking the content a visitor came for. A budget should include a limit on this category specifically — for example, a maximum number of third-party scripts on template pages — because without a limit, this is the category that grows quietly and never gets challenged.

Judging whether a "slow site" complaint is real

Not every complaint about site speed reflects an actual performance problem, and a budget is useful for sorting out which is which. A few checks before assuming the problem is the site itself:

• Check field data, not just a single test. A one-off test from one location on one connection is a snapshot, not a trend. Real-user data (from Google's Chrome UX Report, or an analytics tool that captures Core Web Vitals from actual visitors) shows what typical visitors experience, which can differ substantially from a single lab test run from an office connection.
• Separate the visitor's connection from the site. A complaint filed from a slow mobile connection or a congested network is not evidence the server is slow — though for a site with a largely mobile audience, which describes a great many Malaysian business sites, it is still worth designing and testing for that connection rather than dismissing it.
• Check whether it is one page or the whole site. A single heavy landing page with an embedded video is a different problem, with a different fix, from every page loading slowly.

Diminishing returns are real — say so honestly

Performance work follows a familiar curve: the first improvements — compressing unoptimised images, removing a genuinely unused script, fixing an obvious layout shift — tend to produce large, visible gains for relatively little effort. Beyond that, each additional improvement typically costs more engineering time for a smaller and smaller gain, and at some point the honest answer is that a site is fast enough for its actual audience and further work is better spent elsewhere in the business.

A performance budget is as much about knowing when to stop as when to start. Chasing a perfect Lighthouse score on a page that already passes Core Web Vitals for real visitors is usually not the best use of a maintenance budget — checking that new content and new scripts do not quietly erode what was already fixed is a better ongoing use of the same time.

---

Setting a performance budget once and then letting it slip — an unresized image here, a new marketing script there — is the normal way sites get slow again after being fixed. JagaWeb Care (RM450/month) is one option for keeping an eye on that drift on an ongoing basis. It is not the only way to manage it, and it is not a guarantee of any particular score or ranking outcome — just a standing check against the budget you set. Details at jagaweb.my or sales@jagaweb.my.