A performance budget is a set of agreed limits on the things that make a website slow, such as total page weight, script size, number of requests and load timings. It gives designers, developers and marketers a shared reference point, so a heavy hero video or a new tracking tag has to be weighed against a number rather than argued about by feel. You set it early, measure against it on every change, and decide what to cut when a change breaks it.
Why a budget beats a one-off speed fix
Most sites do not become slow in a single step. They slow down through small additions: another font weight, a chat widget, a larger banner image, one more analytics tag. Each looks harmless. A one-off optimisation sprint removes some of that weight, but without a limit the weight returns.
Google’s web.dev describes a performance budget as a set of limits on metrics that affect site performance, and says it gives designers and developers a shared reference point for decisions about design, technology and features. That shared reference point is the real value. It turns “the site feels heavy” into “this change adds a measurable amount, and we have a limit”.
The three kinds of limit
web.dev groups budget metrics into three types, and a practical budget usually mixes the first two.
| Type | What it limits | Example metrics | Main strength | Main weakness |
|---|---|---|---|---|
| Quantity-based | Counts and sizes of assets | Page weight, image size, script size, number of requests, web fonts, third-party scripts | Easy to explain and check in a build | Says nothing about the order resources load |
| Milestone timings | Moments a visitor notices | First Contentful Paint, Time to Interactive | Reflects the visitor’s experience | Needs realistic test conditions |
| Rule-based | Scores from best-practice checks | Lighthouse performance score | A single number to track | Hides what to fix behind a score |
web.dev recommends combining quantity-based and user-centric metrics, focusing on asset sizes early in a project and tracking milestone timings as soon as possible.
Choosing your first numbers
If you have no data yet, you need defensible starting points rather than perfect ones. The same web.dev article suggests two defaults for teams short on time: Time to Interactive under 5 seconds, and under 170 KB of critical-path resources (compressed and minified), assuming a baseline device and a 3G network speed. It gives the reason that over half of internet traffic comes from mobile networks.
Treat those as a first draft, not a rule. They come from an older article and assume a deliberately slow connection. Your own audience may be on faster phones and networks, or slower ones. Once real-user data exists, adjust the numbers to your audience.
A better route for most business sites is to anchor the budget in the outcomes search and visitors care about. web.dev’s Core Web Vitals guidance sets “good” at a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less, assessed at the 75th percentile of page loads. You can express those as your timing budget, then derive asset limits that make them achievable. Our guide to Core Web Vitals for business owners explains what each metric means in plain terms.
Budget by page type
One site-wide number is blunt. A blog article, a product page and a contact page have different jobs and different weights. web.dev suggests budgets per page type, for example requiring that a blog scores above 80 on Lighthouse performance audits. A simple structure looks like this:
- Landing and home pages: the tightest budget, because they carry the most traffic and the most visual ambition.
- Content pages: a moderate budget, dominated by images and fonts.
- Tool or app-like pages: a more generous script allowance, with a stricter interaction timing limit.
Write each limit down with its owner, the tool used to measure it and the test conditions. A budget without test conditions produces arguments, because two people measuring on different connections will get different answers.
Where the weight usually comes from
Before you set limits, find out what your pages are made of. The common culprits are images, fonts and scripts, and each can have a dedicated limit:
- Images: cap the weight of any single image and require responsive sizes. See responsive images for performance.
- Fonts: limit families and weights. See web fonts and performance.
- Scripts: set a ceiling on first-party JavaScript and a separate count for third-party tags. See JavaScript weight and third-party scripts.
Enforcing the budget
A budget only works if something checks it. web.dev lists ways to add budgeting to the build process using open-source tools: webpack performance features, bundlesize and Lighthouse CI. The principle is that a build or pull request fails, or at least warns loudly, when a threshold is crossed.
Enforcement has two layers:
- In the build: automated checks on bundle and asset size catch regressions before they ship.
- In review: a person asks the budget question when a new feature, embed or tag is proposed, even if no automated check exists.
What to do when something breaks the budget
web.dev gives three responses when a change exceeds a threshold: optimise the existing feature or asset, remove it, or decide not to add the new one. A fourth, quietly widening the budget, should require a recorded decision from whoever owns the business trade-off, otherwise the budget becomes decoration.
This is where marketing and development meet. A new tracking pixel might be worth its cost, but only if someone chooses that knowingly and removes something else or accepts the slower page.
Keep measuring after launch
Lab tests tell you whether a build meets the budget. They do not tell you how real visitors experience the site. web.dev advises continuing to measure after launch and using real-user data to see how changes affect business metrics. Review the budget when you redesign, change platform or add a major feature. Our website launch checklist includes checks to run before a site goes live.
Limits of the approach
A budget is a guardrail, not a guarantee of speed. Hitting every number does not make a confusing page convert. Numbers also age: device and network assumptions change, so revisit them at least when you rebuild.
Where Radiance Impact fits
Radiance Impact’s Technology division builds and redesigns business websites and provides maintenance and care. If you want a performance budget written into a new build or a redesign brief, talk to us through the contact page or read more on the Technology page.
Sources
- Performance budgets 101, web.dev (Google)
- Web Vitals, web.dev (Google)
