What a performance budget is for
A performance budget is a set of limits for how quickly a website should work and how much it should ask a browser to download or process. It gives designers, developers, and content editors a shared way to evaluate changes. Instead of asking whether an image, script, or feature “feels too heavy,” the team can ask what it adds to a page and whether the result still meets an agreed target.
Budgets are most useful when they describe the experience of a particular page type. A text article, product listing, and interactive dashboard do different jobs, so one limit may not fit all three. Start with the pages people rely on most, such as a landing page or a key task page. A small, maintained budget for those pages is more useful than an elaborate spreadsheet nobody checks.
Choose a few measures that reveal different problems
Use at least one measure of what visitors experience. Largest Contentful Paint (LCP) describes when the largest visible content element appears, which can help reveal slow images, fonts, or server responses. Interaction to Next Paint (INP) describes how promptly the page responds to interactions. Cumulative Layout Shift (CLS) captures unexpected movement of visible content. These measures answer different questions; a page can appear quickly but still feel sluggish when someone tries to use it.
Add a few limits that a team can directly influence, such as the transferred size of images and JavaScript or the number of third-party scripts. These are input budgets: they do not guarantee a good experience, but they can flag changes before they reach visitors. Keep the list short. If every file type and every timing becomes a separate target, the important signals can get lost.
Set targets from a repeatable baseline
Before choosing limits, measure representative pages using a repeatable test setup. Record the device profile, network conditions, browser, and whether the cache is empty. Test the same page more than once, because a single run can be misleading. If you have data from real visits, compare it with controlled tests: real visitors use different devices and connections, while a controlled test is easier to repeat after each change.
Then set an achievable improvement target and a limit that should not be crossed. For example, a team might decide that a particular landing page should transfer no more than 180 KB of images during its initial load. That number is an illustration, not a universal recommendation; the right limit depends on the page’s purpose and its starting point. Write down whether each size limit refers to compressed bytes transferred, total resource size, or something else. A budget that people interpret differently will be hard to enforce.
Leave room for expected variation. An article page with one illustration may need a different image allowance from a gallery page. Document those page-type differences rather than quietly relaxing a site-wide target whenever a page exceeds it.
Use the budget when making tradeoffs
Review the likely cost of a change before it becomes difficult to undo. For a new hero image, that might mean checking its display size, format, and whether it needs to load immediately. For an interactive feature, consider the JavaScript it adds, the work it makes the browser do, and whether simpler HTML could serve the same purpose. Third-party tools deserve particular attention because their code and network requests may change outside your release process.
A budget should guide decisions, not forbid useful features. If a change exceeds a limit, ask what benefit it provides and whether another cost can be reduced. You might remove an unused library, defer code until someone needs the feature, or load below-the-fold images later. Record exceptions with a reason and an owner so that a temporary compromise does not become an invisible permanent one.
Make the budget part of routine maintenance
Put the targets where the people changing the site will see them, alongside the test method and the pages covered. Automated checks can flag a larger bundle or a slower test result during development, but avoid treating every small timing difference as a failure. Investigate patterns across repeat runs and look at which resources or tasks changed. When a target is missed, the useful question is what caused the regression and what the team can do about it.
Revisit the budget when a page’s purpose changes or testing shows that a target is unrealistic. Keep a record of old and new limits so changes are deliberate. A practical budget is not a promise that every visitor will see the same speed. It is a decision tool that helps a team protect the experience as content, features, and dependencies accumulate.
