In a constantly changing environment, brands are likely to be iterating on sites and applications to make them bigger, faster, fancier, and more engaging while pushing the new and updated code out as quickly as possible. Without a set plan in place, any new script can damage performance, affecting user experience, and, therefore, business KPIs. We noticed a few common misperceptions about web performance budgets that can impact their adoption and setting that we would like to address.

Five Common Myths About Web Performance Budgets

Myth #1: Performance budgets are ambiguous

Reality: While the setup process can feel daunting if you’re just starting out with web performance, you can take advantage of a few fantastic tools, such as the Performance Budget Calculator app, to set a baseline. If you are already monitoring and optimizing your site for performance, you can also use your existing platform to establish data-based thresholds and set alerts that notify key players when those thresholds are broken. The important part of the process is setting realistic goals based on the current state of your site – goals that can be refined and updated incrementally over time as you move further into improving the site’s performance.

Myth #2: We are not a technology company, and we don’t have dedicated resources to maintain performance budgets.

Reality: If you start incorporating performance now, you won’t have to bake it in later. Even small sites will eventually grow to bigger sites, and along the way, code is going to be added, content is going to be created, and images are going to be developed. If you simply add what you add to the site as your team determines its necessity but without considering its impact on performance, eventually you’re going to wind up with a bloated, slow, poor-performing site that you’ll have to repair. And that will take time, money, and resources that could have been allocated elsewhere.

Myth #3: Our site is relatively small for us to spend a lot of time and resources on a performance budget.

Reality: The smallest sites can experience a degradation in performance over time just like any large ones. Adding one new third-party script to a site without considering the addition’s impact on performance or not managing it within a budget could cause issues at a time when you least expect it. There’s no better time than the present to establish a performance budget, no matter the size of your product.

Myth #4: Web performance budgets add just another step to the process – it’s a waste.

Reality: While it’s true that when there’s a web performance budget in place, teams need to keep it in mind when updating code or site design, this doesn’t have to impact the speed at which these updates happen. Once the budget is fully embedded in the development process, it should simply be another checkbox on the to-do list. Additionally, the budget will save time overall. How? If you make sure that your site is performant at each step of the development process, then teams won’t have to spend more time and money to retroactively make fixes in production – fixes to issues that could impact the functionality of the site and the business’s bottom line.

Myth #5: We can address performance optimization if/when it appears to be a problem.

Reality: Performance isn’t something that you can paint on after the fact – it’s something that needs to be part of the development process from early on. The trouble with making fixes in production is that it takes a team’s time – time that could be better spent creating and developing new, better code for the business – and it also costs the company money. Plus, any performance issues that make it into production will impact the user experience – and cost your business customers and revenue. By establishing a performance budget, that time and money can be saved and reinvested in the company.

What’s Not a Myth? Performance Budgets Are Essential for Your Product – and Your Business

If you look at performance budgets objectively, separating myths from reality, it becomes apparent that they are critical to the success of any performance initiatives, no matter how large or small the company. The key is to start with data based on your site and your competitors’ sites and then to get buy-in from all business stakeholders so that the budget is top of mind throughout the development lifecycle.

What is a web performance budget? A performance budget gives developers and designers data-driven thresholds that they can use when they are designing and building a website or application. There are plenty of resources explaining why a performance budget is important. Here are several that we recommend:

1. Tim Kadlec

Be sure to check out this in-depth piece written by Tim Kadlec about how to make a performance budget stick within your organization (and watch this awesome video, too).

Being concrete means that we have to pick a number and get specific about what we’re after.

2. Milica Mihajlija

CNN JS Parsing
JavaScript processing times for as measured by WebPageTest (src). A high-end phone (iPhone 8) processes script in ~4s. Compare to the ~13s an average phone (Moto G4) takes or the ~36s taken by a low-end 2018 phone (Alcatel 1X).

In her article, Performance budgets 101, Milica highlights the concept of understanding and building a performance budget and how important it is to evaluate your frameworks and libraries based on their size and parsing cost. She does so while referencing one of the most popular articles by Addy Osmani, The Cost of Javascript.

The main idea is to set goals so that you can better balance performance without harming functionality or user experience.

3. Tammy Everts and Katie Hempenius

Web Almanac: Page Weight
We wouldn’t miss mentioning our favorite resource, Web Almanac. In Page Weight, Tammy and Katie offer a wealth of information gathered from to help you get a clearer picture on where you stand compared to your industry peers:

  • Page weight on mobile and desktop broken down by resource type.
  • Change in mobile and desktop page weight since 2018.
  • Mobile and desktop page requests broken down by resource type.
  • Images file sizes on mobile broken down by image format.
  • Cumulative distribution function of GIF file sizes.
  • File size by image format for images > 100 bytes and > 1024 bytes.
  • Video size by media format on mobile and desktop.
Although there are many existing techniques for improving page weight, they won’t make a difference if they aren’t put to use.

4. Addy Osmani

Performance budget calculator
In his excellent article Start Performance Budgeting, Addy Osmani gives a very clear definition of a performance budget as “a limit for pages which the team is not allowed to exceed.” He recommends watching out for JavaScript, image sizes, Time to Interactive, and many other metrics.

Performance budgets are not just thresholds. Much like a financial budget, they’re something consciously spent.

5. Alex RuSSELL

Can I really afford this
In Can You Afford It?: Real-world Web Performance Budgets, Alex reminds us about keeping an eye on how long JavaScript takes to execute and DOM to construct, then how long it takes for the layout processing input (including scrolling with active touch listeners) to manage the main thread.

Living on a budget means constantly asking yourself, ‘Can I really afford this?

6. Mark Zeman

Content RequestsPerformance budgets are an important tool for ensuring your site is delivering a great user experience, according to SpeedCurve’s Mark Zeman in his article Performance Budgets in Action. Mark notes that Steve* first experienced performance budgets while Head Performance Engineer at Google. While this article is from a few years ago, it is in every respect on par with most modern best practices.

*Steve Souders (who requires no further introduction).

It’s vitally important you evaluate which metrics you’ll budget against. For a long time now we’ve known that metrics like the page onload event are terrible indicators of user experience and yet many performance tools and organisations still use it as a key indicator of performance.

7. Zachary Brady

Performance budgetWhen do you decide whether an image slider is so important that it can break your budget or whether there is there a way to decrease its weight or, perhaps, remove other scripts from the page to stay on budget? Set your budget earlier rather than later to prevent the need for reverse engineering later in the process. Zachary offers very useful and practical recommendations in his article Setting a web performance budget.

So I asked myself: what’s the relationship between page weight, HTTP requests, and page load speed? Was there some ratio I could use to determine my performance budget?

8. Google’s Lighthouse

over performance budget
Lighthouse offers a feature where you can maintain a custom performance budget file in which the budget audit would only report on those file types that you’ve specified, as shown in this example. Check out this post on the Web Developers blog for details on how to set up your own custom budget file: Performance Budgets (Keep Request Counts Low And File Sizes Small).

9. Chapman Lever

Performance Budget
Just as a financial budget gives limits on spending for various categories, a web performance budget provides parameters for multiple teams to work within. These parameters affect site performance by setting value limits that a designer or other team member may not exceed when updating or adding components of a website. Ideally, the result is a lightning-fast user experience that stays fast despite any future site changes, argues Chapman Lever (Rigor) in Operationalizing Performance with Performance Budgets.

When you have a clear, pre-defined performance budget that is set out early in the project – before any actual designing begins – you have a structure to gauge your design decisions against.

How Rigor Can Help

Rigor makes performance budgets easier to implement. The Rigor platform can help your business create a performance budget, establish thresholds for user experience and speed metrics, and set alerts for times when the site exceeds the set thresholds. For example, one of the most useful features Rigor offers is the Executive Dashboard, which allows users to easily select the right combination of performance metrics for inclusion and to set the performance thresholds that are meaningful to their unique business goals.

Executive dashboard

If this topic is clearly important to the #webperf community and continuously re-visited, why is there fatigue around the concept of a performance budget? The key is to develop a culture of performance across the business and to establish a performance budget that is used by all teams, including designers, developers, and engineers.

And remember, Rigor can help you deliver actionable insights for optimization to make appropriate tradeoffs, stick to the established budget, help your team align on the importance of web performance, and ensure that your site gets fast and stays fast. Reach out for a free trial to learn more.