Web Development · · 3 min read
Performance budgets for websites — setting limits before you build, not after
Performance problems on websites are almost always cheaper to prevent than to fix. A performance budget defines the limits before development begins and keeps the site fast as it grows.
By Mediseo
Performance problems on websites have a common origin: they accumulate gradually over time. A site that launched at 95/100 on Lighthouse is at 72/100 three years later. Each added image, each new third-party script, each additional font — individually harmless, collectively significant.
A performance budget is a set of defined limits — for page weight, JavaScript bundle size, third-party script count, Core Web Vitals thresholds — that you commit to not exceeding. It prevents the gradual degradation before it happens.
Why performance degrades
Every business need that gets solved by adding something to a website:
- Add a chatbot → +200KB of JavaScript
- Add an A/B testing tool → +150KB plus render-blocking scripts
- Add a video background → +2MB
- Add a cookie consent manager → +100KB
- Add analytics → +50KB
- Update the hero image without compressing it → +800KB
None of these decisions, in isolation, feels like a performance decision. Together, they turn a fast site into a slow one.
Without a performance budget, there's no mechanism for these tradeoffs to be evaluated. The marketing team adds the chatbot because they want the chat functionality; nobody asks what it costs in load time.
Defining your budget
A performance budget should specify:
Total page weight: For a typical marketing page, under 1MB is good, under 500KB is excellent, under 2MB is acceptable. Set a budget per page type (home, service pages, blog posts).
JavaScript bundle size: The most impactful metric for interactivity. Under 200KB compressed is good for most pages. Heavy SPAs go higher; simple marketing pages should be lower.
Largest Contentful Paint: Under 2.5 seconds on mobile 4G. This is the Core Web Vitals threshold.
Third-party scripts: A count limit (e.g., no more than 5 third-party scripts on any page) plus a rule that any new third-party script requires review and approval.
Image sizing: All images served in WebP or AVIF. Hero images under 200KB. All images explicitly sized.
Enforcing the budget in development
Performance budgets only work if they're enforced during development, not audited after launch.
For Next.js projects, the bundlewatch package checks JavaScript bundle sizes against defined thresholds in CI/CD. Build steps that exceed the budget fail, forcing a resolution before deployment.
For images, automated checks via image optimisation pipelines (sharp, imagemin in build scripts, or the Next.js Image component's automatic optimisation) can enforce format and size requirements.
For third-party scripts, a review gate in your deployment process — any new script reference requires sign-off — is a process control rather than a technical one, but it works.
Lighthouse CI can run performance audits on every PR and fail builds that drop below defined scores. Setting Core Web Vitals thresholds as hard requirements ensures performance is treated with the same priority as functional correctness.
The organisational challenge
The harder part of performance budgets isn't technical — it's organisational. Marketing wants the chatbot. Sales wants the live chat. The CEO saw a competitor using a flashy video. Each request is reasonable on its own terms.
A performance budget creates a framework for evaluating these requests against a shared constraint: "We have room for one more third-party script this quarter. Which one delivers the most value?" This isn't a technical conversation; it's a business prioritisation conversation that the budget makes possible.
The alternative — adding everything and then trying to speed it up when the site is slow — is more expensive, harder to do, and often incomplete. You never fully recover from accumulated bloat; you just manage it.
Retrofitting a performance budget
If you're working with an existing site that doesn't have a performance budget, start with an audit:
- Run PageSpeed Insights on your 5–10 highest-traffic pages
- Record current scores and specific metrics (LCP, INP, CLS, total page weight, JS bundle size)
- Identify the biggest contributors to slowness (usually images, then JavaScript, then third-party scripts)
- Set budget targets based on where you need to get to, not where you are now
- Fix the biggest issues to bring you within budget
- Enforce the budget going forward
A performance budget isn't a one-time optimisation — it's an ongoing commitment to treating speed as a product requirement.
Performance is part of how we build and how we think about web development. If your site has drifted and you want to understand what's slowing it down and what it would take to fix, book a call.