A solid strategy for handling performance-related issues like page load time and bandwidth, usage should be at the heart of any website design or redesign.
Unfortunately the web seems to be filling up with otherwise beautiful sites that made limited considerations for how the weight of their pages may affect their users.
Performance should never be sacrificed for the sake of presentation. In fact, studies have found that about 37% of users find site performance to be more important than its functionality, and, even more alarming, 57% of users will leave a site if it takes longer than 3 seconds to load. Thankfully aesthetic value doesn’t have to be sacrificed either—it just requires a little bit of thinking.
A great place to start is by setting a performance budget. A performance budget is a group of limits to certain values that affect site performance, that may not be exceeded in the design and development of any web project.
“Usage should be at the heart of any website design or redesign.”
The term was first used by Tim Kadlec in his 24 Ways article Responsive Responsive Design and elaborated in Setting a Performance Budget. In both he stresses that performance should be one of the first things a team considers in planning a website.
A performance budget provides values against which design, development, content, or any aspect of a site that may affect performance can be made. If including your super awesome image slider on the homepage is going to go over your performance budget, it’s time to decide whether it’s important, if there’s any way to decrease its weight, or if other aspects of the page should be removed to include it. Setting the budget early helps to prevent some backtracking later on in the project.
“A performance budget is a project’s guide towards designing and developing with performance in mind.”
A project’s performance budget is a valuable resource that benefits not only your team but all project stakeholders—and of course the end users.
Note: the rest of this article will be about the thinking that goes into setting a budget. If you want to learn more about the importance of a performance budget and how it can help your next project I suggest anything that Tim Kadlec has written on the subject. Brad Frost also has a wonderful post on how performance should be considered an aspect of design that I highly recommend.
Where to begin
After reading Tim Kadlec’s article, I was an immediate convert. I couldn’t wait to start using a performance budget for my projects. So I took a deep breath and got to it.
Except I had no idea where to begin. I’m a bit of a perfectionist who’s always on the hunt for a reliable yet simple approach to things, so it seemed to me that there should be some sort of equation that would give me the values I needed.
“Performance should be one of the first things a team considers in planning a website.”
While performance is far from being a simple topic, I decided to start from a simplified set of factors and values and build from there. Page weight, the size of a web page in kilobytes including all retrieved assets (styles, scripts, images, videos, etc.), and number of HTTP requests (a request made by the user’s browser to retrieve files needed for the site) seemed like the most likely suspects to be factors in affecting a web page’s performance.
Both of these values have an effect on page load speed and bandwidth use. Of these 2 I decided to focus on page speed since reducing that would have benefits in relation to bandwidth usage as well.
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? I thought about it for a while, gave up, and decided to ask Stackoverflow.
“There are no general answers to your questions. All that can be said is: “it depends”. But there is one sure way to find out what the answers are in your particular situation: try it.”
–Alex D.
And there it was: web performance is too complicated to be boiled down into an equation. The only true way to know something is to try it. Or rather: research and then test your findings.
Doing some research
There are so many factors that go into the performance on a site that the best place to start with determining a budget for your new project is to examine sites that already exist in the wild. I like to look for prototypical pages that represent the conditions of possible pages of the site I’m working on. For instance, if your pages are going to have an image slider you should look for similar pages to base your findings on.
“Performance should never be sacrificed for the sake of presentation.”
In taking measurements, which we’ll discuss in a moment, I still find it useful to focus on page weight, HTTP requests, and page load time. These are the factors you can affect the most and will have the most impact when communicating to the rest of the stakeholders.
If you’re conducting a redesign of an existing site, the best place to look for values is the existing site. It’s likely that the content will stay roughly the same with the redesign, making these the most relevant values you’ll find.
In Designing and Engineering Time, Steven C. Seow posits that a value must change by at least 20% for humans to notice the difference. This is good to keep in mind while inspecting your existing site. To produce a noticeable reduction in your page load time, your new site must reduce load time by at least 20%. If the average load time of a page is 1.5 seconds, you must reduce the load time by at least 0.3 seconds to notice a difference.
The second most important place to find values are competitors’ websites. Framing performance concerns as a “do better than the competitors” narrative is sometimes a useful tactic for adding value to web performance for your stakeholders. This may include the rest of your team, clients, bosses, etc. Also, since your competitors will often have similar types of content, this is another great reference point. I often look at 2 or 3 competitors maximum and thoroughly examine as many pages as necessary.
The third place I often look are similar websites that my team has put out in the past. Although the content may be different, the code will be very similar. Every team has their strengths and weaknesses, and analyzing them through the lens of a performance budget will give you an edge in improving your projects. You also know your own code the best and, in some cases, these readings may be the most tangible in your mind.
Tools to test
When taking measurements during my research I often approach page load time first to get some base values. I use webpagetest.org with the default settings. I’m not looking to get an accurate reading for all possible situations, just a reference point to judge my other values against.
The results are full of other useful bits of information as well. I find the “repeat view” values to be useful in determining how well caching is implemented, and the screenshot helps me determine what the user sees as my pages load. To find the other 2 values, page weight, and number of HTTP requests, I turn to the Chrome Developer tools—specifically the network tab.
The network tab allows you to record how your browser loads a website. You can do this by clicking the circle icon in the top left corner of the view and then refreshing your page. Along with page weight and the number of requests, both found at the bottom, you can also inspect how long it takes for all assets to be loaded as well as what assets were loaded, in what order they were loaded, and how long it took each to load.
An important note is that you should empty your browser’s cache before taking the readings. While it’s also important to inspect the effect of caching on load time, you need to base your findings on the initial page load. To make this simple on myself I use the Chrome extension Clear Cache.
Take a guess: budget estimations
Now that we have some values from our research, it’s time to actually set the performance budget. Keep in mind that this is an estimation as well as a top limit for page weight and HTTP requests, but you should always strive to keep it as accurate as possible.
To keep your estimates as educated as possible, know what content will be included in the site and roughly how the pages will be organized. I tend to wait until the client has delivered all the content so that I can analyze it for hard data, but I’ve set a budget based on expected content when deadlines have been tight but delivery of content has been slow.
I also tend to set an estimated performance budget prior to the creation of the information architecture. This estimate is useful in creating the IA, and a second, more accurate, estimation once I know what pages will have what content on them.
“Have a performance budget in place for every type of page on your site.”
The budgets are ultimately achieved by reviewing your research, understanding your content, and knowing what your pages will include. Keep your goal page speed in mind and use your researched values to make an estimation as to what your limits for page weight and HTTP requests should be. You should have a performance budget in place for every type of page on your site since the content will vary—but not for every page since doing so may take too much time.
Using your budget
A performance budget is a project’s guide towards designing and developing with performance in mind. Whenever a decision is made that may affect performance, the budget should be consulted. The budget becomes extremely helpful when explaining to stakeholders why something can’t be included on a page if it’ll have a detrimental effect to the performance.
Keep in mind that a performance budget isn’t an unbreakable rule. In fact I highly suggest reviewing your budget at key points early in the project to make sure the values you decided on hold up when implemented.
Try not to exceed your original budget. If you find yourself going over it, try to discover what’s causing that to happen. But sometimes it’s better to be pragmatic and make adjustments—just do so as infrequently as possible.
And don’t worry. Your first few budgets may be more guess work than educated estimates, but the more you do them, the tighter your grasp on how different factors affect performance will be.
This was originally posted on the Suits & Sandals blog.
Zachary approaches web development and consultation with a blend of out-of-the-box thinking and logical, clean executions. As Director of Technology at Suits & Sandals, he leads his team in applying this critical thinking to creating intuitive and interactive experiences that address both client and end-user needs.
