The designer sends a homepage mockup with a full-screen background video, three typefaces and an animated counter. Marketing asks for a Meta pixel, a heatmap tool and a review widget on every page. The developer says yes to all of it, because nobody said no. Three months after launch, everyone agrees the site is slow, and everyone has a reasonable explanation for why their part was not the problem.
A website performance budget prevents that conversation. It is a short, agreed set of limits on what a page may contain and how quickly it must load, written down before design starts and checked whenever something is added. The useful kinds of limit are few, they should come from your own site rather than someone else’s numbers, and with a little care they can be used with designers, marketers and developers without turning every request into an argument.
What a performance budget is
Think of it like a household budget. You do not ban spending; you decide in advance how much is available, so each new purchase means checking what is left. A performance budget does the same for a web page. If the page is allowed a certain weight and a certain number of external scripts, then adding a new one means either it fits, or something else goes, or the team makes a deliberate decision to go over and accepts the cost.
The value is not the numbers themselves. It is that speed becomes a shared constraint, discussed at the moment a decision is made, rather than a problem discovered after launch. If you are new to what makes a page heavy in the first place, what page weight is made of explains the parts.
Three kinds of limit
Budgets usually combine three types of limit. Each catches problems the others miss.
Quantity limits
These cap what goes on the page: total page weight, weight of images, JavaScript and CSS, number of fonts, number of external domains contacted. They are easy to check with a browser’s developer tools and easy for non-technical people to understand. A designer can see that a hero video is larger than the whole page allowance.
Timing limits
These cap how long things take, such as the time until the main content appears or how quickly the page responds to a tap. They are closer to what visitors feel, but harder to attribute: a slow result does not tell you which item caused it. Google’s published Core Web Vitals thresholds make a sensible reference: Google rates LCP as good at up to 2.5 seconds, INP at up to 200 milliseconds and CLS at up to 0.1, each assessed at the 75th percentile of real page loads.
Rules
Some limits are better expressed as plain rules: no autoplaying video above the fold, no sliders on landing pages, no new third-party script without removing one or naming an end date, every image resized before upload. Rules are the easiest to apply in a meeting, because nobody needs to measure anything to know whether a proposal breaks them.
Setting a website performance budget from your own site
Do not borrow someone else’s limits. A speed budget for a website has to start from what your site is now and what it needs to do.
- Pick the templates that matter. Usually the homepage, a service or product page, a blog post, and a landing page. Pages built from the same template behave alike, so budget the template rather than every page.
- Measure the current state. For each template, record page weight, the weight of each type of file, the number of requests and external domains, and the timing results from a few repeated tests on mobile. The network tab in browser developer tools shows most of this; checking page load in Chrome DevTools walks through how.
- Decide where you want to be. If the site is already fast enough, the budget can simply be “no worse than today”. If it is slow, set limits a step better than now, which become targets for the optimisation work and limits once it is done.
- Add the rules that reflect your recurring problems. If the last three slowdowns came from marketing tags, that is where the strictest rule belongs.
- Write it on one page and share it with everyone who designs, builds or adds things to the site.
An example budget
The table below shows the shape a budget might take for a small service business. The figures are made up for illustration. They are not recommendations, averages or data from any real site, and yours should come from your own measurements.
| Item | Homepage | Landing page | Blog post |
|---|---|---|---|
| Total page weight on mobile | Example: 1.5 MB | Example: 1 MB | Example: 1.2 MB |
| Largest single image | Example: 200 KB | Example: 150 KB | Example: 150 KB |
| JavaScript (compressed) | Example: 350 KB | Example: 200 KB | Example: 300 KB |
| External domains contacted | Example: 6 | Example: 4 | Example: 6 |
| Font files | Example: two families, four files in total, site-wide | ||
| Largest contentful paint (real visitors) | 2.5 s or less, Google’s “good” threshold | ||
| Rules | No autoplay video; no slider; new third-party script only if one is removed or given an end date | ||
Notice that the landing page is stricter. Pages receiving paid traffic usually deserve the tightest limits, because visitors arrive cold and every one is paid for.
Using the budget with designers
The cheapest moment to respect a budget is in the mockup. Share it with the designer at the start of a project, alongside the brand guidelines, and ask them to note the expected size of large assets: hero images, video, illustrations, animation files. Fonts are another common surprise, because a design that uses three families in several weights can add many files before any content loads.
When a design idea does not fit, discuss the alternative rather than simply rejecting it. A background video might become a still image with a play button. An animated counter might become plain text. Most redesigns that end up slower than the old site, as described in why a new website can be slower than the old one, would have been caught at this stage.
Using the budget with marketers
Marketing tools are where budgets usually break, because each tag looks tiny on its own and each request is urgent. Two rules handle most of it:
- One in, one out. A new tracking script or widget is welcome if an old one is removed, or if the budget has room for it.
- Every test has an end date. Heatmaps, A/B testing tools and campaign pixels are added with a removal date written next to them.
Share the list of current scripts with marketing so they can see what is already there. Often a new tool duplicates something already installed. The broader case for auditing these scripts is set out in how third-party scripts slow pages.
Using it with developers or an agency
Put the budget in the project brief or the contract for any new build or redesign, and make passing it part of what “finished” means. Ask for the budget measurements of each template before launch, taken the same way the baseline was. After launch, check the budget monthly and after major changes; when it is exceeded, record what caused it and decide whether to fix it now or accept it.
When to break the budget
A budget is a tool for making decisions consciously, not a law. Sometimes a heavier element is worth it: a product configurator that sells, a video that explains a service better than any text. When that happens, go over on purpose, write down why, and look for something else to remove to make room. What the budget prevents is going over by accident, one small addition at a time.
A budget is one piece of a wider approach; the how to make a website load faster guide shows where it fits alongside caching, images and code. And if you need to justify the effort to colleagues, how speed affects conversions and sales sets out a fair way to measure the effect.
Frequently asked questions
Does a small business website really need a performance budget?
It does not need a formal document, but it benefits from a few written limits. Even three lines, such as a maximum image size, no autoplay video and one-in-one-out for scripts, stop the gradual build-up that slows most small sites after launch.
Which matters more, page weight limits or timing limits?
Use both. Timing limits reflect what visitors experience, but they do not tell you what caused a problem. Weight and count limits are easier to check when someone proposes a change. Together they catch problems before launch and confirm the result afterwards.
How do I check whether a page is within budget?
Open the page with your browser’s developer tools on the network tab, reload with the cache disabled, and read the totals for size and requests, filtering by file type. For timing, run several mobile tests and use the median, then check real-user data in PageSpeed Insights where available.
What should happen when a page goes over budget?
Find out which addition caused it, then decide together: remove or replace it, make room by removing something else, or accept the overrun deliberately and record why. The important thing is that someone makes the decision, rather than the page simply staying heavier.
A budget needs a baseline, and a baseline is the first thing a speed audit produces. If you want that measured for you, our speed optimisation work begins with an audit of your key pages; the before-and-after figures it ends with make a natural starting point for your limits.
Next in this series: Building a Website for Slow Internet Connections
