September 10, 2020

Performance from a frontend perspective

What performance means and how to quickly improve it

Performance can have a crucial impact on the revenue of a website – for many different reasons. Bad performance slows down your page which leaves most of the users unsatisfied and also runs the risk of being penalized by search engines. But in order to improve it, we first need to understand that from a frontend perspective performance can mean different things. No matter if you are a frontend developer or a site owner who feels like their website is too slow: This article explains the different aspects of frontend performance and some quick wins, which might be worth knowing.

Types of Performance

At Factorial, we differentiate between three types of frontend performance: 

  • load performance
  • perceived performance
  • runtime performance

The load performance basically describes the amount of data – think of it as the weight of a website – that is transferred to the browser of a user when they request your website: the HTML document itself, assets like CSS and JavaScript files and – most important – content like images and videos. While a website can feel fast even though it loads a lot of data (when implemented well), we should still aim to keep this number as low as possible: Bandwidth not only leads to money drain, both for you and your customer, but also to a waste of more energy for your customer’s device and the server your website is hosted on.

The perceived performance describes how quickly your website becomes visible and usable. This is usually directly influenced by the load performance, but as mentioned before, there are techniques to create a fast experience even though your website loads a lot of data.

The last point in our list – runtime performance – points out how your website feels while using it: Are scrolling and animations working smoothly or does it seem janky? Does the user get immediate feedback when clicking a button or does your website not react immediately?

Runtime Performance

Tools for performance analysis

There are many tools and services that allow you to find out what makes your website slow. The most important tools are built-in directly in the browser – usually called devtools (i.e. developer tools) – which allow you to analyze all types of performance.

Online services are only able to look at our first two types of performance – load and runtime performance. While these services can be really helpful to identify problems and their supposable causes, one needs to be aware that these services usually analyze one site of your website and give you tips on how to make this specific site as fast as possible. But they ignore that a user (hopefully) visits not only one site of your website but multiple. And making one site as fast as possible might actually lead to slower performance for subsequent page visits: Imagine your website loads all the stylesheets for your whole website with the first page visit. This would slow down the first page visit, but subsequent page visits would automatically be faster. If you now optimize your website for the first page visit by only serving those stylesheets that are actually needed on that first page, subsequent page visits would be slower. That is because you would then have to serve additional stylesheets needed for those pages.

Quick wins for your website

As you see, there is not just one reason a website is slow and not just one way to make it fast(er). Fortunately, there are some points that are valid for each and every website. As analysing and fixing problems of runtime performance usually requires some deeper understanding of the source code, we will for now focus on load and perceived performance.

Load Performance

Let us first make sure that your website is as slim as possible to increase load performance by taking care of the following points:

  • Compression should be enabled for all files with text content: HTML, CSS, JavaScript, JSON, SVG, and so on. Nowadays usually either gzip or Brotli are used for compression. While gzip is available in basically every environment, Brotli is usually more efficient. Both compression algorithms can be configured to reduce the file size as much as possible, though it would make the decompression slower. So finding a good compromise is necessary. But in general using compression also without configuring it is better than not using compression at all. 
  • All files that should be compressed should also be minified. This means that all unnecessary whitespace, line breaks and other characters get removed and function names get replaced with shorter alternatives while of course making sure that the code still works as expected. Usually this process is integrated in the build process of a website, but can also be done manually with online services like https://www.minifier.org/.
  • Usually, images and videos have the most impact on the weight of a website. So, implementing these as small as possible is crucial. Analogue to text files, images and videos should be compressed, but also be served with the correct resolution. Automating this is possible, but not always easy and it might lead to undesirable results (images and videos are compressed too much and show artifacts). Therefore manually editing of these files is usually better. When you need to use PNG images in your website, you can try out ImageAlpha (https://pngmini.com/). This tool lets you remove colors from PNGs – which by default have 2^24 colors — to a reduced color set of 256, 128, 64 – and so on – colors. Most of the times this is absolutely sufficient and can reduce the file size up to around 80%.
  • In general the choice of the correct image format is very important for keeping the file size as small as possible. The order from large to small is usually PNG > JPG > WEBP (GIF should not be used at all), but there are cases where this is actually not true. So, also here, manually choosing and editing the files is important.
  • Only files that are really needed should be served. Often, when not building a website completely from scratch but by e.g. using a CMS like Drupal, there are also some additional assets like CSS and JavaScript files served, even though they are actually never used. These files should be removed – not only to reduce file size, but also to make sure these files do not conflict with other code in any way.
    Keep in mind though that these files might be used somewhere else on your website. As mentioned earlier, finding a good strategy on how and when to deliver those assets is necessary, but requires a deeper analysis of your website, which is out of scope of this article.

Perceived Performance

Now that we made sure that our website is as slim as possible, let us focus on serving the most important assets first and everything else later. This will improve the perceived performance of your website.

  • Including CSS and JavaScript files is usually render-blocking. This means that as soon as the browsers discovers them in a HTML file, it will download it and only continue to render the website in the browser of a user when the download is done. For CSS files, this is usually the desired behavior because it makes sure that the user does not see an unstyled HTML document until the CSS file is loaded. But for JavaScript files, this is usually different as in most cases JavaScript does not change the look and feel of a website. That is why we can make sure that a JavaScript file is fetched in the background and does not hinder the browser to continue rendering the website. We can do that by adding `defer=”true` to a `<script>` tag. This will make sure that the JavaScript file is downloaded with a lower priority and executed when the whole HTML document is loaded.
  • As mentioned before, using `defer` works in most cases, but especially third party scripts for tracking or analysis rely on being downloaded render-blocking. Keep in mind that these render-blocking scripts would have a negative effect on the performance of your website, so integrating them should be done sparingly.
  • Third party scripts can be especially harming for your website when they are served from another server. If a script is integrated render-blocking and the server is slow, this will heavily slow down your whole website. Or even worse, imagine this external server is not available: This would cause your website to not render at all. Therefore try to always deliver all assets from your own server. This also has the positive side effect that you can make sure that they are cached properly.
  • As mentioned above, images have a big impact on the performance of a website. Therefore a common pattern is to load images only the moment – or right before – an image becomes visible when the user scrolls. This was usually done using JavaScript, but most modern browsers (at the time of writing Microsoft Edge, Mozilla Firefox and Google Chrome) now support setting `loading=”lazy”` on image elements which will give us lazy loading for images natively by the browser.

Wrap-up

What’s the idea of the article: Performance really represents one of the crucial factors regarding your website, that can define whether your users feel comfortable while browsing through your pages — or not. With this article I came up with some steps to easily increase the performance of a website. But consider this: As every website is different and has different requirements, improving the performance to its maximum requires deeper analysis and changes that might be more complex. If you think, there is more to be done for your website, because you really would like to make the best of it, feel free to get in touch with us.

Michael Großklaus

Michael Großklaus

Lead Developer Frontend

Michael@factorial.io