Because nobody owns the speed after launch. A site ships fast, then a chat widget arrives, then a heatmap tool, then three tracking pixels and a video embed. No single addition feels like a problem. Six months later the page takes four seconds and nobody can point to the change that did it.
We see this on almost every site we are asked to rescue. The original build was usually fine. What failed was the absence of a rule that says how much weight the page is allowed to carry, and a check that catches it when the rule breaks.
A performance budget is that rule. It is not a clever technique, it is an agreement, and it is the difference between a site that stays fast and one that degrades quietly for a year.
A performance budget is a set of limits on the metrics that affect how fast your site feels. The Google guidance on web.dev defines it as "a set of limits imposed on metrics that affect site performance", and describes it as a reference point for design and technology decisions.
The important word in that definition is decisions. A budget is not a report you read after the fact. It is a number you check before you agree to add something, which turns a vague conversation about whether a tool is worth it into a concrete one about whether you have the room.
It works the way a financial budget works. You are not saying no to spending. You are saying that spending here means cutting somewhere else, and forcing that trade to be visible.
Three kinds, and you want more than one. The web.dev guidance splits them into quantity based metrics, milestone timings, and rule based metrics. Quantity budgets cap things you can count. Milestone budgets cap how long key moments take. Rule based budgets cap a tool overall score.
Quantity based budgets cover page weight, request count, image sizes, web fonts, script sizes, and external resources. The web.dev guidance notes these are useful in the early stages of development, though on their own they do not fully reflect the user experience.
Milestone timings are the user centred ones, measuring when things actually happen for a real person. Rule based budgets are the Lighthouse and WebPageTest scores, which bundle a lot of judgement into a single number.
Use all three for different jobs. Quantity budgets stop bad additions before they merge. Milestone budgets tell you whether users feel the difference. Score budgets give you one number to report upward.
Start from the published Google thresholds rather than inventing your own. The Core Web Vitals targets on web.dev are Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. Those are your milestone budgets, already defined for you.
One detail people miss is how those are measured. Google assesses them at the 75th percentile of page loads, segmented across mobile and desktop. That means your budget has to hold for the slower quarter of your visitors, not for your own laptop on office wifi.
For quantity budgets, web.dev suggests a baseline of under 170 KB of critical path resources, compressed and minified, alongside a Time to Interactive under 5 seconds. Those figures are calculated against real world baseline devices on 3G, which is a deliberately unforgiving starting point.
The web.dev guidance also recommends analysing the competition to see how you stack up before setting your own numbers. We think that is the right instinct but the wrong ceiling. Matching a slow competitor is not an achievement. Across our projects we hold an average PageSpeed score of 98, and that is the standard we budget to rather than whatever the category average happens to be.
Because a developer can check a quantity budget in seconds and act on it immediately. A JavaScript bundle is either under 200 KB or it is not. A Lighthouse score, by contrast, moves for reasons nobody can trace to a single commit, which makes it useless as a gate on a pull request.
Understanding how the score is built explains why. Chrome documents the Lighthouse 10 performance score as a weighted average, with Total Blocking Time at 30%, Largest Contentful Paint at 25%, Cumulative Layout Shift at 25%, and First Contentful Paint and Speed Index at 10% each.
Chrome also documents that metric values are converted to scores using a log normal distribution built from real website data in the HTTP Archive, where the 25th percentile maps to a score of 50 and the 8th percentile maps to 90. Your score is therefore partly a statement about everyone else sites, not just your own.
That is fine for reporting and bad for gating. Use the score to track direction over months. Use the byte counts to decide whether a change ships.
Put the check in the build, not in a meeting. A budget that lives in a document gets ignored. A budget that fails the build gets respected, because it stops being an opinion and becomes a condition of shipping.
Lighthouse CI can run against every pull request and fail it when a metric or a bundle size crosses your threshold. That single piece of automation does more for long term performance than any amount of good intent.
Set the thresholds slightly tighter than your real limit so you get a warning before you have a problem. If your genuine ceiling for JavaScript is 250 KB, fail the build at 220. The gap gives you room to fix things deliberately rather than in a hurry.
Then review the budget itself twice a year. Devices get faster, expectations get higher, and a budget set three years ago is probably too generous now. The check should get harder over time, not stay frozen.
Whoever owns the conversion rate should own the budget, and in most companies that is marketing rather than engineering. This sounds counterintuitive and it is the single change that makes budgets stick, because the team asking for the script becomes the team paying for it.
When engineering owns the budget, every request becomes a fight, and engineering loses those fights because the business case for a tool is always easier to articulate than the cost of 90 KB. When marketing owns it, the question changes shape. It stops being whether the tool is useful and becomes which existing tool gets removed to make room.
Third party scripts are where nearly all of this pressure lands. They are the easiest thing to add, the hardest thing to remove, and the least visible in any audit, which is why we treat them as their own category in our piece on third party scripts and performance.
Keep an inventory of every third party on the site with the name of the person who asked for it. Half of them turn out to belong to someone who left, and those come off without any argument at all.
You have three honest options and you should pick one deliberately. Optimise something else to make room, remove the new thing, or explicitly raise the budget and record why. What you must not do is quietly ignore the failure, because that is how a budget dies.
Making room is usually easier than teams expect on a first attempt. Render blocking resources in the head are the most common source of cheap wins, and clearing them frees a lot of headroom without touching anything anyone cares about. We covered the mechanics in our guide to render blocking resources.
Raising the budget is a legitimate choice when the new thing genuinely matters more than the milliseconds. The requirement is that somebody writes down the decision and the number. An undocumented budget increase is just a budget failure with better manners.
In our experience the option teams never consider is removal. There is almost always a tool on the page that nobody has looked at in a year, and its cost is real while its value is theoretical.
Indirectly but genuinely. Core Web Vitals are part of how Google evaluates page experience, so holding LCP, INP, and CLS inside their thresholds protects a ranking input you would otherwise lose. The larger effect is on behaviour, because faster pages hold more of the people who arrive.
Be careful not to oversell the ranking effect. Speed is one signal among many, and a fast page with weak content will not outrank a slow page that answers the question better. Budgets protect you from a penalty rather than winning you a position.
The clearer win is on conversion, which is where the money is anyway. A budget that keeps your pages inside the Core Web Vitals thresholds is doing conversion work that happens to also be SEO work. Our fuller take on that relationship sits in our guide to Core Web Vitals and SEO.
There is also a growing crawler argument. Fast, clean pages are cheaper for every automated system to fetch and parse, and more of your visitors now are automated systems.
Measure your current numbers, then set the budget slightly below where you are today. Not at your target, at your current state. A budget you already meet costs nothing to adopt and immediately stops things getting worse, which is most of the value.
Once that holds for a month, tighten it. Improving from where you are is a far easier project to sustain than trying to hit an aspirational number in one leap and abandoning it when the first sprint gets busy.
If you want help setting numbers that fit your site rather than generic ones, or you have a page that has quietly got heavy and you are not sure where it went, we are happy to look. Find us at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.