TL;DR: Setting up a web performance budget involves defining limits on aspects like page size, load times, and HTTP requests to ensure optimal site speed and efficiency. This strategy helps in prioritizing performance goals, catching regressions early, and making informed decisions about technology and design choices. A performance budget aligns with user experience and business metrics, encouraging a disciplined approach to web development and design for better user engagement and SEO.

Optimizing for web performance can be tricky, with lots of back-and-forths.

As the demands of visitors grow so much that a whopping 53% of them would abandon a website that doesn’t load in 3 seconds, online business owners can’t rely on a 90+ speed score alone to keep conversion rates growing.

Enter web performance budgets – the most underrated strategy to set any website up for success.

Whether you're a web developer, designer, or business owner, this guide will help you take your website's performance to the next level.

Let's get started!

What is a web performance budget?

A web performance budget is a pre-defined set of limits your website needs to maintain for optimal speed and efficiency. These limits include:

• Hard resource capping

• Targets for total page weight

• Total number of HTTP requests

• Minimum page load time on mobile networks

• Thresholds for Core Web Vitals metrics (like LCP)

By setting and monitoring a performance budget, business owners, UX designers, and developers can agree and work on mutual performance goals. This way, all collaboration efforts aim for great user experience and even greater business metrics.

Improve Core Web Vitals automatically with Uxify →

What are the benefits of a web performance budget?

What makes web performance budgets so effective is they protect your site against regressions (or help you catch them more effectively). If, in time, you start noticing a drop in performance, you can retrace your steps, perform tests, and troubleshoot much faster.

Additionally, setting web resource usage limits:

• Allows your team to compare and evaluate technologies, different approaches, frameworks, and features

• Can be used to predict trends in resource expenditure and help with better planning (i.e., for the months you spend your budget much faster than usual like the holiday season)

• Can also hint at development and UX design weak points (i.e., finding alternatives to large libraries or web fonts)

⚠️ Performance budgets should not be regarded as expandable but rather as the “money” you spend and exchange for user experience. Much like any other budget, your goal is to do your best to fit within limits and not rely on increasing them. In the long run, this will save you more resources and establish a more streamlined process toward a better user experience.

But how do you decide where to start?

First, you need to better understand what types of metrics you can target in a web performance budget.

Choosing the metrics for your performance budget

Think of these metrics as your goals against which you will measure how effective your budget and site performance gains are.

The types of metrics used for web performance budgeting are:

• Rule-based

• Time-based

• Quantity-based

• Custom

1. Rule-based metrics

They are the round-up site performance scores found in all popular tools, like WebPageTest, Lighthouse, and Google PageSpeed Insights.

Your overall scores are based on both time-based metrics and quantity-based metrics (we go into further detail in a bit).

Not only are they great for tracking your general performance and speed, but the results from your report are solid guidelines for your first budgets. Use them to better understand what you’re aiming for before you move on to more specific and even custom metrics.

Tip: Don’t forget to check the hints and recommendations for improvement in your Lighthouse and Google PageSpeed Insights reports.

2. Time-based metrics

Also called milestone metrics, they are used to evaluate how fast a page loads and what exactly happens during the load. In your reports, these are the user-performance metrics called Core Web Vitals.

Unlike Speed Index and load events, Core Web Vitals help you gain a comprehensive understanding of how real users experience your website in the form of time-based thresholds.

Below are the most important milestone metrics to add to your performance budget:

First Contentful Paint (FCP)

FCP measures how long it takes for the browser to display the first bit of content from the DOM tree (i.e., images, text, etc.) That would be the start of a page load.

Time to Interactive (TTI)

TTI is dedicated to measuring how long it takes for a page to become fully interactive and responsive to user input.

Note: As of the latest Lighthouse 10 update in February 2023, Time to Interactive has been officially removed. TTI’s score weight, which was 10%, is now being transferred to Cumulative Layout Shift (CLS), increasing its overall performance score weight to 25%.

This, however, doesn’t mean TTI is removed from your performance report in Google PageSpeed Insights, for example. But it is a clear hint you might want to think about whether or not it’s a metric worth adding to your budget.

Largest Contentful Paint (LCP)

LCP measures how long it takes the page to render the largest text or image element. It’s a great metric to use in your performance budget as it is user-centric and, after all, preferred by Google.

Interaction to Next Paint (INP)

INP measures the delay between a user’s input (such as clicking a link, tapping a button, or typing into a form field) and the visible response to that input on the screen. This includes the time it takes for the browser to process the event, execute any associated JavaScript, and render any changes to the page.

The goal is to assess how quickly a website responds to user inputs, which is a critical aspect of user experience.

Important: As of March 12, 2024, INP is officially a Core Web Vital metric, replacing FID.

Cumulative Layout Shift (CLS)

CLS quantifies the visual stability of a webpage by measuring unexpected shifts in layout during the page's lifecycle. A low CLS score indicates a stable page, enhancing user satisfaction.

First Input Delay (FID) (deprecated)

FID measures the time it takes for a page to respond to any user interactions, like link clicks, button taps, etc. It captures how well-prepared a page is to load relevant scripts and information to respond to a user’s input.

Important: INP has replaced FID as a Core Web Vital metric and Chrome is officially deprecating support for FID. This means that Chrome tools will no longer guarantee FID availability, and developers and site owners have until September 9, 2024, to transition over to INP.

Total Blocking Time (TBT)

As mentioned above, TBT is related to TTI, but combined with LCP, it gives you a more accurate picture of how users perceive your website. TBT measures how long your webpage was blocked, preventing the user from interacting with it.

3. Quantity-based

Easier to introduce at the start of website development, quantity-based metrics directly link to the number of resources your site will work with for optimum performance.

The most common resources to set limitations on include:

• Language and style size (HTML and CSS)

• Media content size (images, videos)

• Font size

• Script size

• Total page weight

• Total number of HTTP requests

The reason these metrics are more beneficial at the start of a new project is they help teams decide what impact heavier images and scripts will have on performance. However, if you’re struggling with site speed issues, introducing several quantity-based metrics can make choosing which page elements to remove (or substitute) much easier.

Did you know: the median page weight for desktop has grown 221% and a whopping 594% for mobile in the span of 10 years? This ongoing trend reveals a weak point in web performance and an opportunity for site owners to prioritize and optimize page weight in their budgets.

4. Custom metrics

Teams like Twitter have set a custom metric, like “Time to first tweet.” Another common custom metric is “Time to Hero Element.” Depending on what the most important interaction on your website is and how unique it is to your business, you may want to consider tracking it in your web performance budget.

In case you are using browser-specific performance optimizations like navigational speculations, then you may want to consider using metrics like speculation head start or prediction waste.

Tip: Whichever metric you decide to track in your budget must directly correlate to how users experience your website. If, for example, you own a publishing website where text content is dominant, it wouldn’t make sense to add a maximum for video size. Instead, you could focus on metrics like LCP, maximum web font size, and a custom metric like “Time to load H1 title.”

Hit a 90+ Speed Score and pass Core Web Vitals with Uxify →

Prioritizing metrics for a fully-developed website

Deciding on performance budget thresholds with a website in production can be tricky.

The best way to go about it is to start with where you’re at currently. Your primary task will be to prevent regressions and adjust your goals for the future one by one.

If you uncover large performance issues, you might have to consider bigger changes to the website and lower the budgets further after you’ve implemented optimizations.

Read on to learn how to evaluate your current standing, what you should aim for, and how to improve your web performance metrics.

How to set up a web performance budget

Since every website comes with different requirements crucial for competitiveness, your first task is to figure out how they relate to web performance and, more specifically, user experience.

1. Research your competitors

Observing how similar websites to yours perform in terms of speed and user experience will help you:

• Understand what they do well

• Pinpoint areas where you can surpass them

• Build more realistic performance goals and budget limits

Think of overtaking the competition as an ongoing process, not a one-time push. This is why you must weigh how likely you are to gain a competitive advantage without risking your site’s functionality.

There are a couple of ways to find websites similar to yours:

• Search on Google with related:”keyword”

• Use a service like SimilarWeb (the free version is limited but still handy for building an initial list)

Try to find at least ten similar websites to make a solid competitive analysis.

Run targeted pages (home, product, features, blog, etc.) of your competitors through a performance calculation tool like Google PageSpeed Insights.

Next, you might want to list down all performance metric values of your competitors in a chart.

Using tools like WebPageTest and Google PageSpeed Insights, we built this example chart for how BBC compares against The Guarding and the Daily Mail on desktop:

*Disclaimer: The combination of metrics in the example chart above is selected based on the type of website, its competitors, and the supposed priorities such businesses might aim for in this industry. Every case is specific and these metrics shouldn’t be replicated without solid reasoning.

If the Daily Mail performed the same research they would need to map out all the speed-related and quantity-based metrics for their budget to try and close the Speed Index gap.

For a noticeable change against your competitors, you can always refer to the 20% rule when setting up your budget (meaning you want the value to be 20% better than your competitor’s).

Note that even if you’re unable to catch up with your competitors, that doesn’t mean your efforts are not improving the overall user experience for your visitors. Every second faster load time means a 7% increase in conversion rates on desktop and up to 27% for mobile.

2. Create a baseline of your web performance

To create a reliable reference point, use tools like WebPageTest and Lighthouse for relatively stable measurements. Don’t forget to clear your browser’s cache before testing with a browser’s built-in tool. Use the Clear Cache Chrome extension to speed up the process.

You don’t need to run audits for all your web pages. Start with the most important ones that you know (or predict will) attract the most traffic.

Here are example prompts that will help you finalize your list:

• Maximum size of the images to upload to your website (before or after compression) to maintain as small a page weight as possible

• Maximum total page weight for each page

• Total number of HTTP requests allowed per page

• Threshold to achieve a specific Speed Index

• Limits on segmented scripts, like JavaScript, CSS, web fonts

• Total load time no more than X seconds (or milliseconds)

• Google fonts, local fonts, or system fonts (read how you can optimize them for even better results)

Important: According to Strategy Analytics 46% of the total number of mobile users use 2G or 3G. Make sure to test your web pages on slower networks (like 3G) to get a more realistic overview of how people experience your website.

3. Calculate and set your performance budget (+ examples)

Depending on the types of pages you’ve prioritized for performance budgeting, the metric values will vary.

Here are several examples you can start with:

• Page load time under 3 seconds

• Critical-path resources (compressed/minified) under 170KB

• Lighthouse score is >80

A great tool to help you with setting up your budgets for free is Performance Budget Calculator. Choose either Asset or CWV-based budget to specify the metric values you’d like to set and download them in a format ready for Google Lighthouse.

We recommend you start with more manageable higher limits. The initial budget can be “20% faster than my current baseline”. As you optimize, you can aim for more rigorous thresholds like “20% faster than my top competitor”.

4. Implement the performance budget

Please note this step gets more technical, and it’s best to turn to a developer for proper configuration.

Google Lighthouse supports performance budgets via the feature LightWallet available in the command line version of Lighthouse v5+.

To create a budget, you need to open a file named budget.json and JSON following this example by DebugBear:

[
  {
    "timings": [
      {
        "metric": "first-contentful-paint",
        "budget": 1500
      },
      {
        "metric": "largest-contentful-paint",
        "budget": 5000
      }
    ],
    "resourceSizes": [
      {
        "resourceType": "total",
        "budget": 2000
      }
    ],
    "resourceCounts": [
      {
        "resourceType": "font",
        "budget": 5
      },
      {
        "resourceType": "total",
        "budget": 100
      }
    ]
  }
]

Of course, you’ll need to substitute with metrics and values you’ve settled on for your performance budget.

Run Lighthouse to pass in the budget. After that, you will be able to see the values for each of the metrics you’ve set a budget for at the bottom of the Lighthouse Performance section. You will receive notifications if any of the budget thresholds are exceeded.

To add web performance budgeting to your build process, you can check out several open-source tools:

• Webpack (performance features)

• Bundlesize

• Lighthouse CI

Monitor your web performance and adjust budgets accordingly

We can’t stress enough how important it is to revisit your performance reports at least once a month (or whenever you get a notification for exceeded thresholds).

To make sure you stay under budget and never sacrifice user experience, you can:

• Optimize existing website infrastructure, features, and development decisions

• Kill (or substitute) existing plugins and site features that do more harm than good

• Decide not to add a new feature (or third-party solution) altogether

• Use innovative optimization methods like speculative loading

Important: Remember, each site performance optimization you apply needs at least 28 days to be registered in your Core Web Vitals results.

What happens if I exceed a performance budget?

Budgets are not meant to be a bottleneck but rather a signal that action is needed to prevent performance and user experience issues.

Whenever you exceed a performance budget, you and your team can decide to:

• Apply a quick fix (i.e., some type of resource optimization)

• Revert to an earlier stage of new developments (i.e., remove a third-party script that’s not vital)

• Leave it as it is, but schedule future optimizations elsewhere

• Make a trade-off for slightly worse performance and increase your budgets

No matter what approach you take, your end game is to continuously think about performance gains and make conscious decisions based on your reports, analysis, and calculations.

Take it away

Web performance budgets require a long-term commitment from designers, developers, marketers, and stakeholders to ensure excellent user experience is a priority. Implementing a web performance budget not only improves the experience of your site visitors but also boosts SEO, leading to better search rankings and increased traffic.

It’s important both in the early stages of developing a website and as the online business grows. Set and optimized properly, your web performance budget will enable better decision-making, benchmarking, and, ultimately – business KPIs.