Performance Budgets: How to Keep a Fast Website Fast

Short answer: A performance budget is a set of agreed limits that a website must stay within, such as a maximum page weight, a maximum amount of JavaScript, a cap on third-party scripts and target load times like Largest Contentful Paint under 2.5 seconds. It turns speed from a one-time project into a rule: before a new plugin, tracking tag, image or feature goes live, the team checks whether it fits the budget. Budgets work best when they are few, measurable, based on your current site and checked automatically or at every release.

Why fast websites get slow again

Many websites are fast on launch day and noticeably slower a year later. Nothing dramatic happened. Instead, small additions piled up: a chat widget, a second analytics tool, a heatmap script, a new font weight, a larger hero image, a slider on the home page, a pop-up plugin. Each addition seemed harmless on its own. Together they doubled the page weight.

This slow drift is the normal pattern, not the exception. It happens because nobody owns speed after launch, because the cost of each change is invisible when it is made, and because the people adding marketing tags are rarely the people who measure performance. Our article on why websites get slower after a redesign shows the same forces at work during larger projects.

A performance budget addresses the cause. It makes the cost of each addition visible at the moment it is made, and gives the team a shared rule for saying “yes, if we remove something else” or “yes, but load it later”.

What a performance budget contains

Budgets usually combine three kinds of limits:

• User-centred timings. How fast the page feels: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, the three Core Web Vitals. Google’s guidance on Web Vitals treats LCP up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1 as good.
• Quantity limits. Measurable amounts that drive the timings: total page weight, JavaScript size, image size, number of requests, number of fonts and number of third-party domains.
• Score limits. A minimum Lighthouse or PageSpeed Insights performance score for key templates. Scores are easy to communicate but vary from test to test, so use them alongside the other limits, not alone.

Timings describe what users experience; quantities are what the team can control directly. A good budget has both, because a quantity limit tells people what to do when a timing limit is at risk.

How to set your first budget

Start from reality, not from an ideal number copied from somewhere else:

1. Pick the key templates. For most sites: the home page, a service or product page, a category or listing page, a blog post and the checkout or contact page.
2. Measure the current state. Test each template on mobile with PageSpeed Insights or WebPageTest, three times, and note the median values. Record page weight, JavaScript size, request count and third-party domains from the network panel or the test report.
3. Look at field data. If your site has enough traffic, the Chrome UX Report data in PageSpeed Insights and Search Console shows how real visitors experience the pages.
4. Set limits slightly better than today. If pages are already good, set the budget at the current level so it cannot get worse. If they are poor, set a realistic next step, fix the site, then tighten the budget.
5. Write it down in one place. A short table on a shared page is enough. Everyone who changes the website should know it exists.

An example budget for a small business website

The numbers below are an illustration, not a standard. Your own measurements should set the real values.

Keep the list short. Five to seven limits that everyone understands are more effective than twenty that nobody checks. Our guide to page weight helps with choosing realistic size limits.

Turn the budget into decisions

A budget only works if it changes what people do. The practical rules are simple:

• Every new script needs an owner and a reason. Before a new tracking tag, widget or plugin is added, someone checks its size and effect against the budget. The cost of third-party scripts is usually the largest budget risk.
• Something in, something out. When a new feature would break the budget, the team either removes or delays something else, or finds a lighter way to do it.
• Load non-essential things later. Chat widgets, video players and maps can load on interaction or after the main content, which keeps the timings within budget.
• Content rules are part of the budget. Maximum image dimensions and file sizes for editors, a limit on videos above the fold and a ban on autoplaying media all prevent drift from content, not only from code.

Checking the budget automatically

For teams with a development workflow, automation is the most reliable enforcement:

• Build tools. Bundlers can warn or fail when a JavaScript or CSS file exceeds a set size.
• Lighthouse CI. It runs Lighthouse on each change and can fail when a score or metric misses an assertion you define, so a regression is caught before release.
• Scheduled tests. Synthetic tests at fixed intervals on the key templates show trends over time and catch changes that did not go through the development process, such as tags added in a tag manager.
• Field monitoring. Real-user data shows whether visitors actually experience the budgeted values; our guide to website speed monitoring covers the options.

For sites without a development pipeline, a monthly manual check of the key templates against the budget table is a perfectly good start.

Whatever the method, record the results in the same place as the budget, with the date and what changed on the site since the last check. After a few months, that simple history answers the question every team eventually asks: when did the site get slower, and which change caused it?

Budgets for WordPress and other CMS sites

On CMS sites, much of the drift comes from plugins and editors rather than from developers. Adapt the budget accordingly:

1. Keep a list of installed plugins with the reason for each; remove those without a reason.
2. Test a page before and after installing any new plugin, and compare page weight, request count and LCP.
3. Configure image sizes and compression so uploads are resized automatically.
4. Limit who can add scripts in a tag manager, and review its tags every quarter.
5. Check the budget after major theme or page builder updates, which can change the amount of CSS and JavaScript loaded.

Common mistakes with performance budgets

• Measuring only on desktop. Budgets should be set for mobile, where most limits are hit first.
• Budgeting only the home page. Product, article and checkout pages often carry heavier scripts.
• Using a single test run. Results vary; use the median of several runs.
• Setting impossible targets. A budget the site has never met is ignored. Start where you are and improve.
• Never revisiting it. Review the budget once or twice a year and tighten it as the site improves.

How Site AI Audit helps

Site AI Audit measures the numbers a performance budget is made of: the Google PageSpeed score for mobile, the Core Web Vitals LCP, CLS and INP, server response time, compression and page weight. Each finding is explained in plain words and ranked by impact. On paid plans you can re-check after every change and get weekly monitoring, which makes it easy to see when the site drifts outside its budget. See the plans and what each includes.

Related reading

• How Agencies Should Report Website Speed to Clients
• How to Improve Largest Contentful Paint (LCP) on Any Website
• 12 Website Speed Optimization Mistakes and How to Avoid Them

The bottom line

Websites get slow gradually, one addition at a time. A performance budget stops that drift by setting a few clear limits for timings, page weight, JavaScript and third parties, based on your current measurements. Check every change against it, automate the checks where you can, review it regularly, and the fast website you paid for stays fast.

FAQ

What is a website performance budget?

It is a set of agreed limits for how heavy and how slow a website’s pages may be, such as page weight, JavaScript size and load times. New features and scripts must fit within those limits.

What should a performance budget include?

A few user-centred timings such as LCP, INP and CLS, plus quantity limits the team controls, such as page weight, JavaScript size, fonts and third-party domains.

How do I choose the numbers for my budget?

Measure your key pages on mobile, take the median of several tests and set limits at or slightly better than the current values. Tighten them after you improve the site.

Do small websites need a performance budget?

Yes, a simple one. Even a short table of five limits and a monthly check prevents plugins, tags and large images from slowly making the site slow.

How do I enforce a performance budget?

Make someone responsible for approving new scripts, test before and after each change, and where possible automate checks with build tools, Lighthouse CI and regular monitoring.