At Rigor, we believe in being proactive when it comes to managing performance. This means building internal processes and procedures that can help you operationalize a performance-first culture. Creating organizational performance budgets is one of the first steps in this process.

When we think of a budget, what comes to mind is a regular financial budget that functions by giving you limits on spending for various categories. In a similar way, a performance budget in the tech world provides design parameters for the web designer to work within. These parameters affect site performance by setting value limits that the designer may not exceed to the components of a website. The most common feature of performance that the budget considers is a lightning fast load time.

Tim Kadlec, the designer who brought the phrase “performance budget” from governmental budgeting to the tech world, says the performance budget is not just about performance: It’s an essential feature of design, and performance should be front and center in planning a website from its earliest stages. The main goal of a performance budget is to balance user experience with browser experience.

Performance Budgets and Design

Performance budgets are becoming increasingly popular for a few reasons. 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 also create a good starting point to talk about a web page or a website. How nice for designers to know their image and webfont limitations before diving into design. A performance budget also offers a structure to discuss options down the road in deciding what gets added to a page, or not. The budget also keeps your site from getting too big—if you don’t consider performance early and often, there’s a good chance you’ll end up with slow, obese sites. Sometimes an early decision about aesthetics can have serious performance consequences.

It’s easy for designers to get caught up in the design and put performance on the back burner while designing. But every website design and redesign should consider usage at its core, and presentation should never overtake performance. This is because users are impatient, and slow sites lose business. Studies have shown that 37% of users believe a website’s performance matters more than its functionality. Load time matters a lot, as 57% of users will leave a site that takes longer than 3 seconds to load, and 74% of mobile users give the site 5 seconds to load before moving on. A website’s speed makes the difference in whether users actually visit the site or not, so performance matters a great deal.

Designers find a quantitative plan laid out in advance that suggests a Start Render experience of 2 images (~45.6k) or 2 webfonts (~68.4k) while still nailing a 1.197s time is incredibly empowering. These sorts of presets eliminate the performance-based guesswork that accompanies design decisions (or doesn’t), and help ensure the website performs satisfactorily once it’s done. Of course, spending a little time on the performance budget before embarking on a web design can save hours and hours of making changes in the design to speed up performance once the project is in its later stages. In this way, it’s a boon to productivity.

The performance budget brings your focus to performance for the entirety of a project. You stick to the performance goals you have set throughout the whole thing. It doesn’t come into play when you’re deciding what content to display, but it definitely comes in when you’re deciding how to display your chosen content. It’s not a performance strategy to reduce a page’s weight by removing important content, for example.

Instead, the performance budget allows you to consider every decision in the designing process as having performance consequences. When you have a clear, pre-defined performance budget, set out early in the project and 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 why certain features have been omitted or changed.

When you have your budget set up and everyone knows clearly from the very beginning what the budgetary parameters are, you’re saying that performance isn’t a development issue, but a very important piece of the whole package as the site is built. 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.

An advantage of a performance budget set very early in the project is that it helps you understand how much wiggle room you have when making decisions about load speed versus presentation. Working with a budget, you can make a performance sacrifice in one area and then account for that in another. This gives you a chance to think about more complex graphics, for example. If you can improve performance by making cuts in another area, you can add in those complex graphics and stay within your budget. Or perhaps you might want to bring in a few more font weights, which you can do if you take out some image requests. Or you can add a better hero image by making cuts in the marketing tracking script. You can negotiate all of the pieces of a website to find the optimal balance when you are working with a performance budget, and you don’t have to worry that adding in that 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 get that huge image file in.

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

Operationalizing Performance in Design

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 explicitly and frequently bring performance center stage as a primary goal. An example is, “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 will cause some performance problems. Help them think strategically about adding a lot of huge images.

Types of Performance Budgets

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, external to design and in the perceptions of users.

  • Metrics considering time are called “milestone timings”. They measure performance at a single point in time. The shortcoming here is that this metric does nothing to evaluate what happens in between key page-load measurements. That is, 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 the one-second mark. Users may find the second page a better experience, despite the additional 2 seconds it takes to fully load the page. Thus, milestone timings, while useful for essential measurements, show only part of the picture.
  • Quantitative metrics evaluate total number of requests, overall page weight, and total image weight, for example. 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, 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. It’s great for optimizing your site, though may be less effective as 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.

Building a performance budget

When you make 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 to ensure the values you set out are valid once things start to take shape.

To create your performance budget you need to start with some goals, such as a fully loaded page in 5 seconds or less. From there, you try to approximate your budget. This might mean 10 images + 4 webfonts, or maybe 2 images + 10 webfonts, or something else.

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.

Daniel Mall has some good instructions for making a performance budget in his article “How to Make a Performance Budget.” You can check out his original post, or follow his same instructions here with examples from the young women’s fashion industry.

Open a blank spreadsheet and access WebPagetest.

Note** If your organization is using another tool for monitoring site speed and performance you can use the data from that tool instead of WebPageTest, we are using WebPageTest in this example because it is free and can be used by anyone.

Input your website url and let it run. Record the important milestone timings captured for these 3 phases. With WebPageTest the important page timings are: Start Render, Document Complete, and Fully Loaded.

www.forever21.com 0.996s 6.660s 7.733s

From there, you need to check out the competition. Run tests on 3 of your competitor’s sites through and note which one is fastest.

www.hm.com 1.495s 3.012s 4.825s
www.forever21.com 0.996s 6.660s 7.733s
www.charlotterusse.com 1.496s 32.159s 33.147s
www.aeropostale.com 1.394s 13.745s 14.886s

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

Start Render 1.495s 1.196s
Document Complete 3.012s 2.409s
Fully Loaded 4.825s 3.860s

The resulting numbers are your targets. These numbers relate to the constraints you need to consider during design by virtue of your assumed network speed.

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. For the sake of this test we’ll assume that the slowest network is a 3G-connection, and assume a transfer speed of 768 kilobits per second. So we just have to figure out what that means in terms of bytes, not bits. 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 document complete time of 2.409 we can set a quantitative performance budget of 231kb (2.409 * 96).

Document Complete 3.012 289kb
Document Complete 2.409s 231kb
Fully Loaded 3.860s 370kb

With a target kilobyte weight of 231kb at document complete, 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 more likely will need some wiggling.

Screen Shot 2016-06-14 at 10.23.07 AM

Lets 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 perhaps. Now we have a different kind of distribution.

Performance Budget

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

In Summary

Including a performance budget in a web design project from its earliest stages offers all kinds of benefits throughout the design process, and makes for greater confidence that the final product will be as fast as it’s supposed to be. 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. Performance budgets are relatively new in the design process, but are highly valuable tools that should not be overlooked.

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. Click here to try our platform free for two weeks.



Suggested Blog Posts

Mobile Banking a Top Priority for Financials

As mobile devices continue to play a more prominent role in our 21st century society, their usefulness has spread beyond the casual activities of technological enthusiasts. According to research conducted by FUNDtech, a rapidly growing number of ba...

Read More

The Perception Gap for Poor Web Performance

E-commerce is a growing source of revenue for many companies and businesses, as it continues to capture market-share from brick-and-mortar stores over recent years. However, many businesses are not prepared for this growth of online business becau...

Read More

Measuring Cross-Browser Performance

In recent years, client-side browsers have been more involved with processing code before it reaches the user's desktop, shifting away from a reliance on servers handling the bulk of this burden. Websites and applications now rely more on a user's br...

Read More

Using Browser Trends to Maintain a Better Site

Because of the multifarious nature of web clients today, it’s important to consider the usage statistics when designing, implementing, and managing your site. However, misconceptions often arise when determining what browsers to design for an...

Read More