What Is a Performance Budget? How to Set Limits That Keep Your Site Fast

In short, a performance budget turns speed from a one-time project into a lasting rule. At Talha Aslan and team, we see the same pattern in the field again and again. A site launches fast. Then, month after month, teams add a slider, a chat widget, and a new tracking tag. A year later, nobody remembers why the page got heavy. A budget exists to stop that slow buildup.

This guide covers the metrics a budget uses, how to set your first limits, how to enforce them across a team, and how to monitor them in Search Console. We label every sample number as an "example scenario." Your real targets depend on your site and your users.

What problems does a performance budget solve?

Most speed problems do not come from one big mistake. Instead, they come from many small decisions. For example, marketing asks for a new tag, a designer suggests a larger hero image, and a developer adds a library. Each decision looks reasonable on its own. However, the total slows the page down.

A budget gives everyone a shared language. The debate moves from "the site feels slow" to "the home page went over its JavaScript limit." As a result, decisions rest on an agreed limit rather than personal taste. The web.dev article Performance Budgets 101 also describes a budget as a reference point for design, technology, and feature decisions.

• It keeps speed visible whenever you add a new feature.
• Design, development, and marketing get the same target.
• It catches regressions before release, not after users feel them.
• Speed work becomes an ongoing discipline instead of a single project.

Which metric types belong in a performance budget?

web.dev groups budget metrics into three types. This split matters because it tells you where to check each limit. Therefore, your first step is to pick at least one metric from each group.

In practice, the strongest budget combines all three. Quantity limits guide daily development work. Timing limits protect the user experience. Finally, a rule-based score works as a quick health signal.

How do you set limits for page weight and request count?

Quantity-based limits are the most concrete part of a budget. First, split the resources on a page by type: images, JavaScript, CSS, fonts, third-party resources, and the total. Then set a separate ceiling for each type.

For teams without time for competitor research, web.dev suggests a starting point of under 170 KB of compressed, minified critical-path resources. That figure assumes a slow mobile network and a mid-range device. In other words, it is a starting point, not a rule. An image-heavy catalog needs different limits than a text-heavy blog.

Request count deserves its own line, too. Third-party requests in particular (ads, analytics, chat, maps) tend to grow over time. So we recommend a separate limit for third-party requests. To cut image weight, see our guide to optimizing images for speed and SEO, and for a quick try, use our image resizer tool.

Why should JavaScript get its own budget?

JavaScript costs more than an image of the same size. After the browser downloads it, the browser also has to parse, compile, and run it. That work keeps the main thread busy, and the page then responds late to clicks. For that reason, a separate JavaScript limit makes sense, independent of total weight.

One of the sample budgets on web.dev reads: a product page ships less than 170 KB of JavaScript on mobile. The same source also suggests stricter JavaScript limits for image-heavy sites, because images already use up most of the total budget.

For a deeper look, read our article on how JavaScript affects site speed. From a budget point of view, the key question stays simple. Does each new library give users enough value to justify its cost?

What LCP, INP, and CLS targets should a performance budget use?

Core Web Vitals form the backbone of a timing budget. According to the web.dev Web Vitals page, a good experience means LCP (Largest Contentful Paint) at 2.5 seconds or less, INP (Interaction to Next Paint) at 200 milliseconds or less, and CLS (Cumulative Layout Shift) at 0.1 or less.

You assess these thresholds at the 75th percentile of page loads, split by mobile and desktop. That means most of your visitors should stay within the target. A page passes only when all three metrics meet their targets.

We explain each metric in our Core Web Vitals guide. For budgeting, our advice stays simple. Treat the official thresholds as a ceiling, and set your own target a bit tighter. That way, a small regression does not push you straight into the poor range.

What eats into an LCP budget?

The LCP element is usually the largest image or the largest block of text on the page. As a result, server response time, hero image size, render-blocking CSS, and late-discovered resources eat most of an LCP budget.

1. Measure how long the server takes to send the first byte.
2. Identify the LCP element; most of the time it is an image.
3. Check the size and format of that image.
4. Make sure it does not load lazily; never lazy-load the image in the first viewport.
5. Reduce render-blocking CSS and font files.

For example, if your home page LCP target is 2 seconds, you can split that time into parts. Give a share to server response, resource discovery, download, and rendering. This is an example scenario. Its purpose is to show which part breaks the budget. For detailed techniques, see our LCP optimization guide.

Why can't you measure an INP budget in the lab?

INP depends on real user interaction. It tracks the delay between a click, tap, or key press and the next frame the browser paints. According to web.dev, 200 milliseconds or less counts as good. Between 200 and 500 milliseconds needs improvement, and anything above 500 milliseconds counts as poor.

However, lab tools such as Lighthouse cannot measure INP, because no real user takes part in the test. For that reason, web.dev suggests Total Blocking Time (TBT) as a lab proxy. Your budget therefore needs two separate lines: a TBT limit for the lab and an INP target for the field.

In budget terms, the most effective step is to limit scripts that keep the main thread busy for long stretches. Long tasks often come from heavy event handlers, large third-party bundles, or work that could wait until after the first interaction.

How do you set your first performance budget step by step?

The web.dev guide Your first performance budget recommends starting with measurement and comparison. We follow a similar order on client sites.

1. Pick key pages: the home page, your highest-traffic category or product page, and your best-converting landing page.
2. Measure today's values, separately for mobile and desktop.
3. Compare similar sites by testing the same page type of a few competitors under the same conditions.
4. Set a long-term goal; web.dev suggests being at least 20% faster than the fastest competitor.
5. Set a realistic first budget; if the goal feels far away, start 20% faster than where you are now.
6. Add quantity and rule-based limits for JavaScript, images, request count, and the Lighthouse score.

Example scenario: the example.com home page has a mobile LCP of 4 seconds today. The long-term goal sits under 2.5 seconds, and the first budget lands at about 3.2 seconds. Once the team reaches that interim goal, it tightens the budget to the next step.

Do different page types need separate budgets?

Yes, they do. A blog post and a product listing page carry very different content. Consequently, one shared limit ends up either too strict for one page or too loose for the other. web.dev also recommends separate budgets for different page types.

The limits in this table are example scenarios. Fill in the values from your own measurements. What matters is that you know the most critical item for each page type.

How do you check a performance budget with Lighthouse?

Lighthouse can read a budget from a file. According to the web.dev guide to Lighthouse budgets, this file usually goes by the name budget.json. It can hold three kinds of limits: timings (in milliseconds), resourceSizes (in KB per resource type), and resourceCounts (requests per resource type).

When you run Lighthouse from the command line with this file, the HTML report shows a Budgets section under the Performance category. That way, you see at a glance which resource type went over and by how much. The same guide adds an important caveat. Lighthouse produces lab data, so you should compare its results with field data from real users.

If you are new to Lighthouse reports, start with our Lighthouse performance test guide. On the rule-based side, web.dev offers a Lighthouse performance score of at least 85 out of 100 as a sample limit.

How do you tie the budget to your development workflow?

A budget that lives only in a document fades within weeks. The real value appears once you connect it to your build and release process. web.dev lists three open-source options: webpack's built-in performance hints, bundlesize for checking bundle sizes, and Lighthouse CI for comparing Lighthouse results against your budget.

For instance, if you run Lighthouse CI on every pull request, a change that breaks the limit shows up before it merges. Then the team picks one of three paths. It optimizes the existing feature, removes something else, or decides not to add the new feature. web.dev suggests the same three options.

Even if you cannot set up automated checks yet, a weekly manual test and a simple spreadsheet beat having no budget at all.

How do you get a team to follow a performance budget?

The technical part of a budget is easy. The hard part is getting people to respect it. So frame the budget from day one as a shared agreement, not as "the developer's job."

• Name an owner who updates the budget and approves any overrun.
• Teach marketing one question to ask before adding a tag: which budget line does this spend?
• Share image and font limits during design, so designers work within them from the start.
• Log overruns as exceptions, with the date, the reason, and a rollback plan.
• Review the budget every quarter and tighten any target you have reached.

The most common mistake we see in the field: only one person knows the budget. When that person leaves, the budget leaves too. Therefore, we recommend writing the limits into project docs, design files, and the release checklist.

How do third-party scripts break the budget?

Third-party scripts are the sneakiest consumers of a budget. Someone adds them once, and then nobody questions them again. Moreover, these scripts can trigger new requests on their own and add weight without you noticing.

The Lighthouse budget example on web.dev includes a separate limit for third-party request count. We recommend the same on every project. In addition, run a tag inventory at least once a year: which tag is active, who asked for it, and does it still serve a purpose?

On the other hand, some scripts are truly necessary. The goal is not to remove them all. Instead, choose their load timing and priority on purpose. For example, loading a chat tool only after user interaction can free up room in the initial load budget.

How do you calculate an image and font budget?

On most sites, images make up the largest share of total weight. That is why we suggest splitting the image budget into two parts: the first viewport and the rest of the page. Images in the first viewport affect LCP directly, while images further down can arrive later through lazy loading.

Example scenario: a service page has one hero image and a small logo in the first viewport. The team gives the hero image a set KB ceiling and the logo a much smaller one. It then tracks the reference images lower on the page against a separate total. As a result, a designer who wants to add an image knows which line the image spends from.

Fonts also carry a quiet cost. Every extra weight (light, bold, italic) means another file. The quantity-based examples on web.dev include the number of web fonts. In practice, one or two font families with a limited set of weights protect both the budget and design consistency. Also choose the font loading behavior on purpose, so text does not stay invisible while the font loads.

In short, make image and font decisions together with the budget during design. Shrinking things afterward always costs more than designing within limits from the start.

Why should the mobile budget be stricter?

Mobile devices run with tighter limits on both processing power and network speed. The same JavaScript file may run quickly on a powerful laptop, yet it can keep the main thread busy far longer on a mid-range phone. Consequently, a separate and stricter mobile budget makes sense.

The web.dev first-budget guide illustrates this gap. It suggests a smaller critical-resource limit on a slow mobile network and a larger one for desktop on Wi-Fi. Also, you assess Core Web Vitals thresholds separately for mobile and desktop. A good desktop result therefore cannot hide a mobile problem.

So how do you know which devices your users have? web.dev recommends the Chrome User Experience Report to check your audience's device mix. The device breakdown in your analytics tool helps, too. If most visits come from mobile, run your tests with a mobile profile and a throttled network.

What is the difference between a performance budget and speed optimization?

Speed optimization covers the work you do to fix an existing problem: compressing images, removing unused code, tuning cache settings, and so on. A performance budget, by contrast, is the rule that stops those gains from slipping away over time. Think of one as treatment and the other as prevention.

Here is an example scenario we often run into. A site reaches good values after a thorough speed project. The team relaxes, and within a few months new additions push the numbers back to where they started. The issue in that case is not the quality of the optimization. Rather, nobody set a budget afterward.

That is why the last step of every speed project should record the new values as a budget. For example, measure the home page JavaScript size after optimization and make it the ceiling, plus a small margin. That way, you keep the speed you gained. For the rest of your technical checks, see our technical SEO tips.

How do you monitor a performance budget in Search Console?

Keeping the budget in the lab is not enough. You also need to track what real users experience, and the Core Web Vitals report in Search Console is the most practical place for that. According to Search Console Help, the report uses real-user data from CrUX (Chrome User Experience Report). It labels URL groups as Poor, Need improvement, or Good.

Each group takes the status of its weakest metric. So even if LCP and CLS look good, a poor INP drags the whole group down. After a fix, you start validation with Start Tracking on the issue details page. Google then watches a 28-day window to see whether the issue comes back.

If Search Console is new to you, start with our guide on what Google Search Console is and how to use it. For budget tracking, we suggest checking this report at least once a month.

How do lab and field data work together in a budget?

Lab data comes from a controlled setup with a fixed device and network. That makes it ideal for catching regressions during development. Field data, on the other hand, shows what real users experience across many devices and connections. Still, it takes time to build up.

A good budget links the two. You check lab limits on every pull request, and you track field targets in the monthly report. If the two disagree, your lab setup probably does not reflect your real users. For example, if most visitors use mid-range phones, testing on a powerful desktop will mislead you.

web.dev also mentions the web-vitals JavaScript library for collecting your own field data. With it, even small sites that lack enough CrUX data can run their own measurements.

What should a monthly performance budget report include?

Monitoring only pays off with a regular report. We suggest a short, repeatable format to our clients. The goal: anyone should understand the status within two minutes.

• Budget and actual value per page type for weight, JavaScript, and request count.
• Lab results, including the Lighthouse performance score and TBT.
• Field results, meaning the Good, Need improvement, and Poor split in the Search Console Core Web Vitals report.
• Change from the previous month and the releases behind it.
• Open overruns, with an owner and a target date.

Share this report with non-technical stakeholders as well. Then, when marketing or management brings a new request, they already know the state of the budget, and you make the call together. Over time, the report history also becomes a useful archive of which change affected speed and by how much.

Does a performance budget guarantee rankings?

No, it does not. Google's page experience documentation states plainly that good results in reports do not guarantee top rankings. The same page also notes that Google tries to show the most relevant content, even when the page experience is sub-par.

So why does a budget matter? When many helpful pages compete for the same query, a strong page experience can make a difference. Speed also shapes user behavior directly. A visitor who leaves a slow page reads nothing and fills in no form. In other words, a budget is not a ranking lever on its own. It is the infrastructure that delivers the value of your content to users.

In our SEO work, we treat speed together with content, technical structure, and links. Through our SEO consulting service, we set up a performance budget tailored to your site and track overruns together with your teams.

What should you do, in order, when you go over budget?

An overrun is not a disaster; it is a signal. What matters is following a calm order instead of installing random plugins in a panic.

1. Find which line went over: images, JavaScript, third parties, or server time.
2. Find when the overrun started; recent releases and new tags usually give a clue.
3. Look for easy wins such as uncompressed images, unused code, and extra fonts.
4. If that is not enough, weigh the feature's value, then remove it or load it later.
5. Confirm the fix in the lab, then wait for field data to settle.

If you follow this order, you lower the chance of facing the same problem a few months later, because you have recorded the root cause.

What are the most common performance budget mistakes?

Many teams that set up a budget fall into the same traps. Knowing them up front saves time.

• Looking only at the Lighthouse score, while the real user experience gets worse.
• Setting one limit for the whole site and ignoring page type differences.
• Making the target too strict on day one, so the team soon stops taking the budget seriously.
• Testing only on desktop and missing the mobile experience.
• Stopping measurement after launch; web.dev also advises continuing to measure after launch.

Put simply, a budget is a living document. A budget you write without measuring, or never open again, is no better than having none.

Who should help you with a performance budget?

For a small site, your own team can set up a basic budget. Pick a few pages, measure them, and set simple limits. However, on sites that several teams touch, that change often, or that run complex setups such as online stores, building the budget into your processes takes more experience.

At that point, outside support can make sense. You can request a quote on our SEO consulting page. We measure your current values, propose budgets per page type, and track overruns with you through a monthly monitoring report. We do not promise rankings. Our goal is speed that delivers your content to users without friction.

Whichever route you choose, the first step stays the same. Measure your current values, pick your three most important pages, and write down a limit for each one. Even a small budget, tracked regularly, helps you keep your site fast for years.

Core guide: What Is Digital Marketing? Its types, examples and how it is done, on one page with an interactive film that travels through the brain.