The conversation that doesn't happen in most web projects: at the start of the engagement, what speed does the site have to load at? Specifically, in numbers, with a way to measure whether the launched site hits the target.

The reason it doesn't happen is that "fast" sounds like an aesthetic goal, not a measurable one. Both the agency and the client mean "it should feel snappy" and assume that's a shared understanding. Six months after launch, the site lands at LCP 4.2 seconds on mobile, the client complains it feels slow, and the agency points at design decisions the client signed off on as the cause.

The fix is a performance budget. It's not a complicated concept and it should be in every web project quote you receive. My position is that any agency that won't commit to a performance budget at proposal stage is either inexperienced or planning to ship a site that's slower than it should be.

This post is what a performance budget is, what numbers belong in one, and why the quote in front of you should already have one written into it.

What a performance budget actually is

A performance budget is a set of explicit numerical limits for the website's loading and runtime behaviour. The agency commits to building the site within those limits. The numbers are measurable, the commitment is contractual, and the budget functions as a constraint that influences every design and engineering decision during the build.

A typical performance budget for a modern marketing site has four or five numbers:

Largest Contentful Paint (LCP): under 2 seconds on mobile, under 1.5 seconds on desktop
Interaction to Next Paint (INP): under 150 milliseconds across the experience
Cumulative Layout Shift (CLS): under 0.05
Total page weight (initial load): under 800KB
JavaScript bundle size (gzipped): under 200KB for the main bundle

These numbers translate to Lighthouse mobile scores in the 95+ range and pass all three Core Web Vitals thresholds. They're not theoretical — they're achievable on modern frameworks like Next.js 16 and Astro 5 without exotic optimisation. The budget makes them explicit.

Without the budget, the same project gets built without these constraints. The hero video that's 4MB gets approved because it looks great in design review. The third-party analytics script gets added because someone in marketing requested it. The custom font gets used in three weights because the brand specified it. Each individual decision is reasonable. The cumulative effect is a site that lands at LCP 3.5 seconds and INP 280ms and feels slow.

Why budget enforcement matters

The two states a website can be in: meeting Core Web Vitals or not. Google's own data shows sites that pass all three CWV thresholds see 24 percent lower bounce rates and measurably better search rankings. The 200ms INP threshold is the most commonly failed in 2026 — 43 percent of sites fail it, even after years of effort to improve it.

For a commercial site, the consequence is direct. Every 100ms of load time costs roughly 1 percent of conversions, per the consensus measurements from Akamai, Walmart, and others over the last decade. A 500ms improvement in load time on an Australian e-commerce site generating $10M annually translates to roughly $500,000 in recovered revenue.

These aren't aspirational numbers. They're measured trade-offs between speed and revenue. The performance budget is the mechanism that ensures the website gets built to capture them.

What goes in the budget

A complete performance budget includes several categories of constraint.

The user-facing performance metrics

The Core Web Vitals are the foundation:

LCP (Largest Contentful Paint): when the largest element of the page renders. Good: under 2.5 seconds.
INP (Interaction to Next Paint): how responsive the page feels to user interaction. Good: under 200 milliseconds.
CLS (Cumulative Layout Shift): how much elements move around as the page loads. Good: under 0.1.

A serious performance budget targets the "Good" thresholds plus a margin for safety. Targeting LCP 2.5 seconds is the bare minimum; a serious budget targets LCP under 2.0 seconds because you want some headroom.

The resource budgets

The user-facing metrics are influenced by what gets shipped to the user. The resource budgets constrain that:

Total page weight on initial load: under 800KB for marketing sites, under 1.5MB for content-heavy or commerce sites
JavaScript bundle size (gzipped): under 200KB for marketing sites, under 350KB for application-heavy sites
Number of HTTP requests on initial load: under 30
Image budget: total image weight under 400KB on initial load, individual images optimised and served in modern formats (WebP, AVIF)

The third-party budgets

Third-party scripts are the leakiest part of any performance budget. Analytics, marketing tags, chat widgets, A/B testing tools — each one adds weight, blocks the main thread, or both.

A reasonable third-party budget:

Maximum 4 third-party scripts on production
Total third-party script weight: under 100KB
Each third-party script must be loaded asynchronously and not block the critical render path

The biggest performance regressions on marketing sites I see come from third-party script bloat. Six chat widgets, three analytics platforms, two A/B testing tools, and a partridge in a pear tree. The budget puts a hard cap on this.

The build and CI budgets

Performance budgets aren't just numbers on a doc. They get enforced in the build pipeline. Tools like Lighthouse CI run on every deployment and fail the build if the site exceeds the budget. The result is that performance regressions can't ship to production without being explicitly approved.

This is the structural enforcement that makes a budget useful. Without CI enforcement, the budget is a wish that gets ignored as new features get added.

How the budget shows up in the build

A performance budget influences specific design and engineering decisions during the build:

Image strategy

A budget that caps total image weight forces a real image strategy. Images get optimised, served in modern formats, sized appropriately for the viewport, and lazy-loaded below the fold. The framework's image component (Next.js's next/image) handles most of this automatically when used correctly.

Without a budget, designers spec 2000px wide hero images on mobile and nobody catches it.

Font strategy

A budget that caps page weight and JS bundle size constrains font usage. Three weights of a custom font instead of seven. Self-hosting the font instead of pulling it from a third party. Using font-display: swap to render content before the font loads.

Without a budget, every brand-mandated font weight gets loaded and the LCP suffers for it.

Third-party script strategy

A budget that caps third-party script count forces conversations about which scripts are actually necessary. The marketing team's request for a sixth analytics tool gets pushed back against because it would breach the budget. The conversation moves from "we want this" to "what are we taking off to make room."

Without a budget, every script request gets approved because no individual one feels expensive.

Framework and architectural decisions

A budget influences the choice of framework. A site with a strict performance budget on a content-heavy use case argues for Astro (ships 0 to 5KB of JS by default) over Next.js (ships 90 to 150KB on content pages). A site with significant interactive features argues for Next.js with Cache Components to minimise the dynamic portion. The budget makes the architectural trade-off explicit.

Why most quotes don't include one

The honest reason performance budgets aren't standard in Australian web project quotes:

Some agencies don't have the engineering depth to commit to specific numbers, so they keep performance vague.
Some agencies know their typical builds don't hit aggressive performance targets, so they avoid making promises they'd have to keep.
Some agencies treat performance as a post-launch optimisation problem rather than a build-time constraint.
Some clients don't ask for it, and agencies don't add things to proposals that clients don't ask for.

The structural fix is for clients to ask. A question as simple as "what performance budget will you commit to in this proposal?" forces the conversation and surfaces whether the agency takes it seriously.

What to ask the agency

Specific questions to put performance budget into the conversation:

"What LCP, INP, and CLS will the site hit at launch, measured on a mid-range mobile device on a 4G connection?"
"What total page weight will the initial load be? What's the JavaScript bundle size?"
"How will the performance budget be enforced during the build? Is there CI enforcement?"
"What happens if a feature request would breach the budget?"
"Can you show me past projects with public Lighthouse scores so I can see what you typically deliver?"

The first question is the diagnostic. An agency that names specific numbers — "LCP under 2 seconds, INP under 150ms, CLS under 0.05" — is committing. An agency that says "we'll aim for the best performance possible" isn't committing and is reserving the right to ship something slow.

What the budget should look like in the contract

A performance budget in a web build contract should be a numbered section, typically half a page:

Performance Budget

The Contractor will deliver a website meeting the following performance criteria, measured on the homepage and three other priority pages identified in Schedule C, using Lighthouse on a simulated mid-range mobile device with 4G throttling:

Largest Contentful Paint: under 2.0 seconds

Interaction to Next Paint: under 150 milliseconds

Cumulative Layout Shift: under 0.05

Total page weight (initial load): under 800KB

JavaScript bundle (gzipped): under 200KB

Lighthouse mobile performance score: 90 or above

Verification will be conducted on the final pre-launch staging build, with results documented and provided to the Client. If the launched site fails to meet any criterion, the Contractor will undertake remedial work at no additional charge to bring the site into compliance, before the engagement is considered complete.

This is a contractual commitment. It makes performance enforceable rather than aspirational. The agency that won't sign a clause like this is either inexperienced or planning to deliver a site they don't want to be measured against.

What this means for the budget you're holding

If you have a web project quote in front of you and it doesn't mention performance specifically — no numbers, no measurement methodology, no remediation clause — that's a meaningful gap. Either ask for the performance budget to be added before signing, or recognise that the agency hasn't thought about it and you may end up with a site that's slower than the market expects.

A performance budget adds approximately zero cost to the project when it's in the proposal from the start. It can add significant cost as a retrofit if the launched site needs to be re-engineered to meet performance targets that should have been baked in.

A starting point that costs nothing: run a free audit on whatever site you've got now. You'll get the real LCP, CLS, and INP numbers on mobile and desktop, plus the specific issues dragging each one down. Those numbers are the floor your new build has to clear — and they're also the numbers you can paste straight into the performance clause when you're negotiating the quote.

Performance Budget: Why Every Quote Should Have One (2026)