Design Development

Performance Budget – Website Optimization the Right Way

Performance Budget - Website Optimization the Right Way

On the front–end side of web development, performance is something that should not be ignored. What’s more, to show how important the performance is, new thing called performance budget appeared. Today, you are going to learn what performance budget is, why is it not so easy to set it and what ways and tools you can use to meet your budget.

What is performance budget

Have you ever played with network tab in the browser’s web inspector? If not, you should give it a try right now. You can learn tons of information about the website just by using this single tool. For now, the most important parts will be time and size, especially time. If you like colors and graphs, timeline can be interesting for you as well. As you might already guessed, performance budget is about the time it takes to load the website (time column).

Let me repeat it in simple terms. Performance budget is the available time you set for the website to load. You performance budget can be as small as two seconds or it can be five seconds or even more.

How high should be your performance budget

One question you might think about now is how high your performance budget should be. Well, this is a tough question to answer. Every website is different and will have different requirements and possible places for improvement. Meaning, for smaller size website like portfolio or simple blog, three or four seconds to load are pretty bad performance. On the other hand, for a large–scale site like an e–shop or another content heavy website this can be very good number to get to.

I think that there is no one size fits all answer for this question. You will have to analyze the scale at which you are working, compare it with the competition and create average figures for orientation. Next step is to use these figures and work your ass off to get better performance than them using the techniques described below.

The question of perceived performance

Along with performance budget there is something you should keep in mind as well. It is a perceived performance. Meaning, how is the performance perceived by the user. In other words, does the website looks like it is loading fast? Does it looks like it takes a century to load everything? Does the website load at all? Numbers can tell you one thing, but don’t rely on them. Your users will not care about those numbers. If they will think it is too slow, there is no number that will convince them otherwise. Always bulletproof your numbers and results by testing perceived performance–ask the users.

How to increase the performance

Let’s take a look at few techniques you can use to improve the overall performance of your website and delight your clients and users.

Minify, minify and minify

One thing you should do every time when you move from development version to production–deploy all the files to the server–is to minify the CSS and JavaScript code. You can do the same thing with HTML as well if you want, but the difference will be minimal. If you have no idea what minification is, it is a technique of reducing the file size of scripts and stylesheets, and increasing the performance, by removing white space and comments from the code. As a result, you will get one large, and hard to read, block of code.

You can do this either by some of the online tools–copy and paste the code, process it and then save it into new file–or you can use automated solution in the form of service that will do all the hard work for you on the server-side. It is similar to loading fonts over CDNs. You can find more about minification in one of the older posts dedicated to this subject.

Optimize it before loading it

JavaScript and CSS are not the only assets you can optimize to increase the overall performance of your website. Images, audio and video can be optimized as well. For these types of assets, optimization comes in two forms. First, you can increase the performance by decreasing the quality, resulting in smaller file size, lower bandwidth and higher loading speed. Second, you can use tools dedicated to this kinds of tasks.

In case of images, for example, these tools use advanced algorithms to reduce the file size by removing unnecessary data and reducing the quality. This reduction of quality is done in a degree not visible to human eye (without zooming in). In other words, images looks the same, but the final file size can be reduced by more than sixty percents. Great tools for image optimization I use on a daily basis are JPEGMini for jpeg and jpg files and PNGoo for PNG files.

De omnibus dubitandum est

Let me translate this one into more suitable form. This quote by Søren Kierkegaard in English stands for “Everything must be doubted.” Meaning, in every situation you are about to load some assets, whether it is from CDN (Content Delivery Network) or your own server, you should ask yourself if the asset is necessary. Even better, ask if that version of that assets is necessary to load at this situation. Let’s bring in more clarity by providing an example.

You have a website, say an e–shop, with dozens of images. These images will already make ton of http requests slow the site down. Since you are well-rounded front–end developer, you have every image duplicated and optimized for retina screens. In the majority of cases, getting rid of these images is not an option, at least not viable one. However, there are few things you can do. First, you should use simple media query to manage when to load which version of images. Below is CSS and Sass mixin.

CSS:

@media only screen and (-webkit-min-device-pixel-ratio: 2),
only screen and (min--moz-device-pixel-ratio: 2),
only screen and (-o-min-device-pixel-ratio: 2/1),
only screen and (min-device-pixel-ratio: 2),
only screen and (min-resolution: 192dpi),
only screen and (min-resolution: 2dppx) { ... }

Sass mixin:

@mixin retina {
  @media only screen and (-webkit-min-device-pixel-ratio: 2),
  only screen and (min--moz-device-pixel-ratio: 2),
  only screen and (-o-min-device-pixel-ratio: 2/1),
  only screen and (min-device-pixel-ratio: 2),
  only screen and (min-resolution: 192dpi),
  only screen and (min-resolution: 2dppx) {
    @content;
  }
}

Using this media query or mixin images for optimized for retina screens will be loaded only when the user will be using device with this type of screen. Otherwise, regular image will be served. As a result, you will get lower bandwidth and better performance.

Another smart thing you can do is to use a bit of JavaScript in the form of lazy loading plugin. This is technique where the images will be loaded and rendered by browser only when user will reach certain threshold. In other words, images under the fold will not be loaded until user will scroll down. Then, JavaScript will do its job and load the necessary images. If you want to cover the possibility of unavailable JavaScript, as you should, you can use noscript tags and wrap the original images inside. Performance will go up significantly.

Similar thing can be applied to CSS by having more stylesheets, one for every page, and loading only the stylesheet needed that is need. Since CSS stylesheet (minified) is not so big, the difference will not be that significant like with images, but you will see some small gains.

If you can, merge it

The last thing to boost the performance of your website is to merge all the assets you can. This means that production version can use one huge minified CSS stylesheet instead of multiple. The same thing for JavaScript. If you are using images for icons and other small assets, you can create a sprite using a generator and load this instead. Sprite is one image file containing number of smaller ones. Individual images are then access by X and Y coordinates.

The goal of merging the assets is to lower the number of http request. To explain it, every file the website needs to load is one request send to the server. All these requests are shown on the network tab in browser’s web inspector. Here, you can also see if they were successful or not. Whether you understand this or not, all you need to know is that the smaller the number of requests is, the better.

Closing thoughts on performance budget

Setting a performance budget is one thing. Another one is doing your best to achieve it. Remember that the majority of user will be willing to wait only for certain amount of time. Then, they will leave your website and may never come back. Will you make the effort to create a performance budget for your project? In case you are working in a team, how does your colleagues approach this topic? Do you talk with your clients about it?

What is your experience with improving the performance and managing the performance budget?

If you liked this article, then please consider subscribing.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.