Reading time 9 min

When it comes to managing web performance, it’s vital to be proactive rather than reactive. To accomplish this goal, an organization needs to build internal processes and procedures that can operationalize a performance-first culture. The first step is to establish and implement web performance budgets.

According to Tim Kadlec:

A performance budget is a clearly defined limit on one or more performance metrics that the team agrees not to exceed and that is used to guide design and development.

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.

Web Performance Budgets Are Like Financial Budgets

Tim Kadlec, the designer who brought the phrase “performance budget” from the financial world to the tech world, says that a performance budget is an essential tool for incorporating speed as a feature of page design and ensuring that web performance is front and center in website planning from its earliest stages. The main goal of a performance budget is to balance user experience with browser experience.

Benefits of Web Performance Budgets

A website’s speed makes the difference in whether users visit a site or not, so performance matters a great deal. Studies have shown that 39% of users believe a website’s performance matters more than its functionality. Load time is critical, as 53% of mobile users will leave a site that takes longer than three seconds to load.

Performance budgets help to create a faster user experience and keep the speed consistently fast as iterations are made over time. The benefits of performance budgets include:

  • They bring performance to the attention of designers and allow it to be treated as a fundamental design feature rather than simply a best practice.
  • They create a good starting point to talk about a full website or individual page or section from a performance and design perspective.
  • They provide the structure and context to discuss what can or cannot be added to a page in the future in relation to performance impact.
  • They can keep a site from becoming too big, unwieldy, and user-unfriendly.
Performance budgets can help not only make a site faster but also keep the site speed consistent as iterations are made over time. #webperf #perfmatters Click To Tweet

Additionally, a performance budget brings the team’s focus to performance for the entirety of a project. All involved will be working to stick to the performance goals that have been set. The budget comes in not when the team is choosing what content to include but when deciding how to display chosen content that has been deemed important.

A performance budget forces the team to consider web performance in every decision of the design process by quantifying the consequences of those decisions. 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. An added advantage is that the performance budget helps explain to stakeholders in data-based terms why certain features have been omitted or changed.

Identifying the Importance of Performance

When you have your budget set up and you have aligned all team members on its parameters, you’re establishing performance as a core pillar of the site’s functionality. The performance budget provides a guide for design and development while considering performance, and it should be consulted with every decision that might affect performance.

Performance Budget Guides Design

By setting a performance budget early in the project, rather than shoehorning it in later on, designers and other team members will understand how much wiggle room they have when making decisions about speed versus presentation. By working with a budget, a team member can make a performance sacrifice in one area and then account for it in another.

For example:

  • You can add in complex graphics by making cuts in another area to improve performance and stay within your budget.
  • You can bring in more font weights by removing some image requests.
  • You can add a higher-quality hero image by making cuts in the marketing tracking script.

In other words, you can negotiate all of the pieces of a website to find the optimal balance when you are working with a performance budget. You don’t have to worry that adding in a huge image file will slow down your site because you know that you have to account for that huge file by taking something else out — and you know the number of bytes you have to finagle to fit in that huge image file.

The optimal size of the performance budget will vary with each project. A good rule of thumb is to start smaller rather than larger.

Start Smaller with Web Performance Budgets

Operationalizing Performance Throughout the Design Process

Brad Frost lays out tips to bring performance consideration into the design process. They are as follows:

  1. Include performance in project documents. All written materials regarding the design should frequently and explicitly bring performance center stage as a primary goal. For example, “The goal of this project is to create a beautiful, impressive, lightning-fast user experience…”
  2. Put designs in the browser as soon as possible. The design needs to be considered effective once it’s live. Today, we can much more quickly and easily see the performance implications of design decisions than previously.
  3. Collaborate. Developers and designers should be working together from the beginning, and developers need to identify possible performance concerns in wireframes and comps. This process needs to be truly collaborative — a joining of the disciplines rather than crossed-arm grunts of assent.
  4. Educate. A lot of designers are simply unaware of the performance consequences of their design decisions. They need help understanding that bringing in five font faces, for example, could cause some performance problems. Help them think strategically about any design changes they introduce.

Types of Performance Budgets

Tim Kadlec identifies a few types of metrics, each of which helps meet one or both of the dual goals of prioritizing performance – which is internal to those constructing the site – and building a fast-feeling site – which is external to design and in the perceptions of users.

  • Metrics considering time are called “milestone timings.” Traditional milestone timings include Document Complete and Page Load Time – metrics that represent key technical milestones that were easy to measure. As web performance as a discipline has matured, newer user-centric metrics have been developed, such as Time to First Paint, Time to Interactive and Visually Complete, that look closely at key milestones in the user experience. We advocate that when you develop your performance budget, you focus on these user-centric milestones over technical milestones. The shortcoming with technical milestone timings is that these metrics do not always effectively capture the user’s experience. For example, one page may take only 3 seconds to load but the user cannot see anything until 2.5 seconds, while another page may need 5 seconds to load but most content displays at 1 second. Users may find the second page a better experience, despite the additional 2 seconds it takes to load the page fully. This is why focusing on the user-centric milestone timings listed above is a better practice.
  • Quantitative metrics evaluate total number of requests, overall page weight, and total image weight. They don’t tell a lot about the end-user experience because they depend on how a page requests these resources, but they help in the design stages.
  • Rule-based metrics such as PageSpeed, YSlow, Lighthouse Score, or Rigor’s performance score can be used as budgets. These tools assess your site based on a list of performance rules and give your site a grade. These metrics are great for optimizing your site, though they may be less effective within a budget because they don’t say anything about the quality of the user experience with a page, regardless of that page’s grade. These are better used as tools to ensure you haven’t overlooked any optimizations.

Getting Started with Your Performance Budget

When you create a performance budget, you have to review your research, know your content, and be aware of what’s going into your pages. Remember your target page speed and rely on your researched values to estimate limits for page weight and HTTP requests. Keep reviewing your budget at key points in the development process to ensure the values you set out are valid once things start to take shape.

Remember to start with some goals, such as, “We want to have a fully loaded page in 5 seconds or less.” From there, try to approximate your budget. This might mean something like: “We can incorporate 10 images + 4 web fonts or 2 images + 10 web fonts.”

To get your goal figures, check out your competitors’ websites and make sure yours is well below theirs. Another option is to work with the industry standards and shoot for two seconds or less total page time, knowing this is what users expect.

Step-by-Step Creation of a Performance Budget

Daniel Mall has some good instructions for developing a performance budget on his blog. Check out our example exercise that follows his methodology using the free tool WebPageTest. (Of course, you are welcome to gather data from whichever monitoring solution your organization uses, following the same steps laid out below to interpret that data.)

While Daniel focused on Start Render, Document Complete, and Fully Loaded, which are technical milestones, we are going to focus on Time to First Paint, Time to Interactive, and Visually Complete, which are more user-centric metrics.

1. Open a blank spreadsheet and access WebPagetest. Input your website URL and let it run.

Put Your URL in WebPageTest

2. Record the important user-centric milestone timings captured for the URL, as noted above.

SITE NAMETIME TO FIRST PAINTTIME TO INTERACTIVEVISUALLY COMPLETE
www.myclothing123.com0.996s6.660s7.733s

3. Next, check out the competition. Run tests on three of your competitors’ sites and note which one is fastest.

SITE NAMETIME TO FIRST PAINTTIME TO INTERACTIVEVISUALLY COMPLETE
www.competitor1.com1.495s3.012s4.825s
www.myclothing123.com0.996s6.660s7.733s
www.competitor2.com1.496s32.159s33.147s
www.competitor3.com1.394s13.745s14.886s

4. Research has indicated that people notice speed differences in websites when there is a 20% difference in load times, either faster or slower. Thus, you want to calculate your target metrics to be 20% faster than your fastest competitor.

CURRENT TIMETARGET TIME (20% FASTER)
TIME TO FIRST PAINT1.495s1.196s
TIME TO INTERACTIVE3.012s2.409s
VISUALLY COMPLETE4.825s3.860s

Daniel Mall recommends setting milestones for the slowest of your end-user’s connection speeds. Using your website’s web analytics software, you can view the various network connections and identify the slowest popular networks for your audience.

5. For the sake of this test, we’ll assume that the slowest network is a 3G-connection with a transfer speed of 768 kilobits per second. One byte = 8 bits, so 3G is about 96 kilobytes per second. This number will give us what we need to calculate some ballpark conversions.

With a target Time to Interactive of 2.409, we can set a quantitative performance budget of 231kb (2.409 * 96).

TARGET TIMEKILOBYTE WEIGHT
TIME TO FIRST PAINT3.012s289kb
TIME TO INTERACTIVE2.409s231kb
VISUALLY COMPLETE3.860s370kb

6. With a target kilobyte weight of 231kb at Time to Interactive, we have a starting place to begin mapping out how much space can be allocated to each website feature. The total can be split evenly to provide a starting place but will likely need some tweaking as you finalize your budget.

HTML Chart

7. Let’s assume that most of the JavaScript on the page isn’t critical to rendering content on the page, so we can reallocate that part of the budget to something more crucial to the user experience, like images. This leads to a different distribution:

chart

When the total parameters for the website are laid out before you, you can more powerfully make decisions about what to include where and remain confident that performance won’t be compromised by those decisions.

Conclusion

Including a performance budget in a web design project from its earliest stages offers all kinds of benefits throughout the process and makes for greater confidence that the final product will be optimized for speed.

The performance budget brings together designers and developers in important conversations about how best to optimize a particular website and helps designers ensure that design doesn’t overtake performance. It offers clear, preset parameters for each component of the website and, when followed carefully, results in an optimal final product that meets everyone’s expectations and projections the first time around. Be sure to include user-centric metrics into your performance budget.

Interested in creating performance budgets for your website? Rigor helps digital companies create and manage performance budgets of every type (milestone timings, quantitative, and proprietary rules-based metrics) to immediately diagnose the performance impact of code or design changes before they impact your users. Contact us now to start your free trial.

 

Suggested Blog Posts