One recent trend in web design is the use of a hero image. A hero image is a large background image at the top of the page and it offers a quick overview of what the site is all about. Some suggest that when done well they lead to higher conversion rates. However, a large image adds weight to your page and could reduce site performance. Should you use a hero image?
A page that takes too long to load usually means fewer people sticking around, which typically means fewer sales and conversions. I’ll ask again, should you include the hero image in your design?
There’s no right or wrong answer. Like most web design questions, the answer is “it depends.” If your page weight is already low and you make only a few HTTP requests, the image probably won’t slow things down noticeably. On the other hand if your page is already pushing against the limits of performance, you may not want to include the image. Your choice to include or not include the image comes down to the specific goals you have for the page and the site.
This is the third post in a short series about website performance. I began with an introduction and then last week talked about what happens from the time you request a web page in a browser until the browser displays the page. Today I want to talk about setting performance goals with a performance budget.
A Performance Budget is Another Design Constraint
Design is about tradeoffs. If you want more battery, you probably need to design a bigger phone. If your goal is a thinner phone, you have to accept it’ll have less battery. A decision to include something on a web page is also a decision not to include something else.
Designers work within constraints as part of the job. Our client sets a budget, which places limits on what we can do. We might need to design to match a logo and have to work with a particular set of colors or use a specific font because it’s in use on all the client’s printed material.
The idea behind a performance budget is similar. You set constraints for the design and development of the site based on performance goals. For example, you might decide the page needs to load in under 3 seconds or make no more than 5 additional HTTP requests. Maybe the constraint you set is for the total page weight to never exceed 100kb.
If the hero image you want to add leads to load times greater than 3 seconds or becomes the 6th HTTP request or leads to an overall page weight larger than 100kb, you can’t add it unless you make some performance tweaks to stay within the budget. Once you set a performance budget you live within it.
Why Set a Performance Budget?
The main reason to set a performance budget is because it helps to maintain a conversation about performance throughout the life of the project. Since you have to live within the constraints of the budget, performance is a consideration at every step. It’s not something you tack on at the end.
The budget will also get you to think about and understand the performance consequences of any of the decisions you make from early in the design phase right through the end of the development phase of the site.
How Do You Set a Performance Budget?
Is it more important that the page weigh less than 100kb or that it loads in 3 seconds? What about the number of HTTP requests? Which metrics are the most important to know? Where should we look to set performance goals and create a performance budget?
One of the reasons I’m writing this series is so I can answer questions like these. Most of the articles I’ve read about setting performance budgets ultimately pointed me toward an article by Tim Kadlec about performance metrics . He categorizes performance metrics as one of four types.
- Milestone timings
- SpeedIndex
- Quantity based metrics
- Rule based metrics
Milestone timings are metrics that answer the question how long does it take. How long does it take to for the page to completely load? How long does it take for the page to start rendering? These metrics are easy to describe and measure, but they all suffer from the problem that no one metric tells the whole story. Each is based on a single point in time and you need to consider several of these metrics together for a more complete picture.
Daniel Mall offered an interesting take on using milestone timings in your budget. Daniel suggests measuring the start render, document complete, and fully loaded times for your site and then doing the same for three competitor sites. I’ll talk about measuring these next week.
If the fastest start render time among the sites tested is 2.5 seconds, you might set a goal of 2.0 seconds for the start render time of your site
Notice that 2.0 seconds is 20% faster than 2.5 seconds. The 20% number comes from a statistic that says people perceive tasks as faster when they’re at least 20% faster so it makes for a significant, yet likely realistic, goal.
Daniel also suggested converting the timing goals to file weights by considering the transfer speeds (in kilobytes per second) of the connection being testing. For example, if the connection is 96kb/s and your goal is 2 seconds to start render, then everything needed to render the page needs to weigh 192kb or less
96 × 2 = 192
SpeedIndex is a metric available only through WebPageTest. It’s an attempt to measure the average time when the visible parts of the page are displayed. SpeedIndex tries to measure the overall experience or the perceived performance. It’s expressed in milliseconds and a lower score is better.
The downside of SpeedIndex is that it’s hard to explain exactly what SpeedIndex is so you have to trust that it does what it says it does. It is, however, a single metric from a site being developed mainly by Google who has an interest in improving the performance of web pages and has done a lot of work in that regard.
Quantity based metrics are metrics that describe how much or how many. How many HTTP requests? How much page weight? How much do the images weigh? The scripts? Quantity based metrics are also easy to describe and measure, but they don’t really tell you much about the actual experience.
Your visitors want to start taking in your content as soon as possible. Reducing the weight of a CSS file will help, but knowing you reduced it by 10kb doesn’t give you any specifics about whether or not performance was improved for the visitor, at least not without a conversion like the one Daniel Mall talked about.
Rules based metrics are scores from tests such as Google’s PageSpeed or the open source Yslow. Both provide a grade for your site based on the measured performance and they offer a checklist of things you can do to improve your score. Tools like these are how I’ve generally gone about measuring and trying to improve performance in the past.
The downside of these tools is that they don’t always tell you how to make the suggested improvements and when they do it’s often code you copy and paste without really understanding how it works or even why you might not want to implement it.
At the end of his article, Tim Kadlec, says he bases his budget on SpeedIndex and/or a combination of milestone timings. I think that makes sense.
When I worked to improve site performance in the past, I always set timing goals, though back then I was less nuanced and my only goal was to keep the complete load time below 8 seconds or 5 seconds or whatever the goal might have been.
SpeedIndex didn’t exist at the time and now that it does and I’m aware of it, it’s a metric I want to know and improve. Both the quantity and rules based metrics strike me more as numbers you want to know to make actual performance changes, but they don’t lend themselves as goals that belong in a budget.
Closing Thoughts
Hopefully that gives you a better idea of why you want to set a performance budget and generally what types of metrics you should use to set goals.
Remember that your goal isn’t necessarily to make every performance improvement that can be made. Performance goals need to be considered in the context of other goals for the site. You want to weigh performance gains and losses against aesthetic pros and cons and other design considerations.
The key idea with a performance budget is that by setting one you add important constraints to the design so that performance can be considered throughout the project instead of trying to tack it on at the end.
Next week I want to talk about tools, specifically the one at WebPageTest, that will test your site and provide the metrics you’ll use to guide your performance budget goals. I’ll also walk through a waterfall diagram that shows all the resources required to load the home page of this site and how long it takes to load.
Download a free sample from my book, Design Fundamentals.
I’m in the process of redesigning my site and this information is very useful. It gives me a good launch platform to have a conversation with the individual who will be helping me redo the site. Am looking forward to reading the next article.