Graphics optimisation for websites - an introduction

Graphics optimisation for websites - an introduction

The process of creating a website is complex. It consists of, among other things, the graphic design phase based on the provided requirements and the accepted draft.

At this stage, beautiful layouts are created containing a huge number of graphics, which the client can manage freely at a later date. After making a few changes, the client is delighted, and the project goes to the developers. After several weeks, the big day arrives - the time to launch the service. Suddenly, the first problems appear: the website starts to run slowly. We check the codes, and there are loops and other critical places that can cause users to spend, at most, a few seconds on that page.

Seemingly everything is fine; after all, "it works fine at my place". We open the console in the browser, refresh the page and to our eyes, we see a volume of downloaded data that makes us dizzy. Ultimately, we could track down the culprits - a lack of graphic optimisation.

In this article, I want to go deeper into this topic and give you a good dose of knowledge. I will cover both the basic concepts and the more complex ones to illustrate how to optimise your site graphics. We will focus mainly on practical things so that you can move straight into the action. Interested? I invite you to read on.

Do we need graphic optimisation that much? After all, in large cities, many people have a connection to the network via optical fibre.

Moreover, it is becoming increasingly popular even in smaller agglomerations. Considering this, whether we download 5MB of data or 40MB doesn't interest us because it will still take a while with a connection of up to 600Mb/s, right? You are right; however, this topic needs to be looked at more broadly. To analyse it carefully, let us first note which devices we like to use and how this trend has changed over the years.

(source: https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/worldwide/#monthly-201201-202211)

As you can see, 2012 was mainly dominated by wide-ranging desktops, while mobile devices accounted for only a few per cent. However, with advances in technology and the development of networks, we have moved from the 3G standard to LTE and 5G. These days, it is easy to see that we do most of our daily business using mobile devices.

Well, okay, but after all, I'm connected via Wi-Fi at home, so everything still works quickly. This is true, but you are probably often away from home, such as at school, work, a café, a shopping mall or just on your way to a meeting. You are using your phone then, searching for information online, browsing social media or watching videos on Youtube.

In some places, you can connect to 'free Wi-Fi' but I strongly advise you against this option for security reasons. If not connected to Wi-Fi, downloading 40MB of data several times would result in your internet limit being exhausted once two. You would probably not be happy with that.

I will mention at this point a situation that happened to me recently. As I was not pleased with the coverage of one operator, I had to port my phone number to another phone provider. Unfortunately, during the number porting process, the lady dealing with the order incorrectly transcribed the number, resulting in complications. The suggested solution was that the number would be transferred first to a pre-paid service and then on the same day to a post-paid service. The thing is, I had to top up my account for a few hours to be able to use the phone freely. I decided that probably 20zł would be enough for the moment.

Before launching my internet package, I reflexively switched on my browser and visited one of the news sites. To my surprise, after 15 minutes, I received an SMS that the funds in my account had been used. Of course, I realised my mistake; however, it encouraged me to check how much data I had actually 'burned through' for that amount.

As it turned out, I used ~160MB of data for about 15 minutes. I will point out that I did not turn on any videos or visit Youtube. With this example, I wanted to show you how the proper management of graphics on a website can make a difference to the end user.

Let's also turn our attention to some interesting data from 2016, which shows how long a user can wait for a page to load.

As you can see, around 53% of users do not stay longer than 3s for a page to load. In my opinion, the percentage was already much higher in 2022. This information can be crucial for someone who deals extensively with online sales.

Let's take the example of the page https://www.magneticpoint.com. Let's see how we can check this using the Firefox browser.

  1. We enter the address in the browser.
  2. Enable the network tab using the keyboard shortcut cmd + opt + e (ctrl + alt + e) or by right-clicking on the page and then selecting 'inspect', where the 'network' tab is selected. 
  3. Refresh the page using the keyboard shortcut shift + cmd + r (refresh with cache disabled) or by holding shift and clicking on the arrow next to the url.

Once this has been done, we will have detailed information on the resources that are downloaded by the site. The less critical columns in the image below have been hidden, so the view presented may differ slightly from yours.

In the screenshot above, we can notice:

  1. The number of requests made to the server - - if you are not using HTTP2, this also affects the page loading speed.
  2. The amount of data expressed in MB that has been transferred to the browser.
  3. Loading time for the first-page view - on the left-hand side, you may notice a message with the text 'Finish'. This value can change with the asynchronous recharging of resources.
  4. Records sorted by bin size - here, we can identify the potential 'culprit' responsible for the slow loading of the page.
  5. Names of bins.

As we can see, the website https://www.magneticpoint.com was loaded in around 600ms and downloaded less than 1.5MB in the process. Let's filter the results to leave only the graphics to see if they take up so much space relative to the whole and whether it makes sense to bother with them. Click on the 'images' tab on the right-hand side of the page.

Next, let us take another look at the results obtained.

We can see that the browser downloaded 19 graphics, which together 'weighed' just under 1.2MB. Putting this together with the total amount of data downloaded, this is as much as 80% of the total. Of course, it is still only 1.2MB, so the page loads in a flash. With this example, I want to highlight the essence of the problem and signal the importance of optimising graphics.

At the end of this paragraph, I want to give you an example of one of the websites that can literally 'eat' your transfer in the blink of an eye.

As you can see, the browser has downloaded as much as 22MB out of almost 40MB, where the first five graphics account for about 70% of the total transfer. It would have been easy to reduce the size of each of these graphics to around 500kB, which would have reduced the amount of data transferred from 22MB to 8.5MB, and this was achieved by optimising the graphics alone.

In this paragraph, we look closely at the PageSpeed Insights tool to see how Google treats our site. Let's once again take the page https://www.magneticpoint.com. Without further ado, let's get straight to the tests. Let's go to pagespeed insight and type in the address of the page we want to check. After a short analysis time, we get results for mobile and desktop devices.

On both mobile and desktop devices, the results obtained are excellent. As you can see, the tool allows you to examine, among other things:

  • Performance,
  • Accessibility,
  • Good practices,
  • SEO.

In addition, if there are problems, the tool will tell you what to correct.

In contrast, let's type in the address of a page that previously took us as much as 22MB and sees how things are going in this case.

From the above, performance does not look good. There is something to work on here to make the site more user-friendly. Optimising resources and reducing the number of queries would significantly improve the performance of this site.

At the end of this paragraph, I recommend GTmetrix tool, which also analyses pages for performance. Below is the report for the desktop version of the website https://www.magneticpoint.com.

Once we know how to analyse the site in terms of performance, it's time to delve deeper into the topic of what graphic format to choose, as it may be obscure.

The number of available graphic designs we use online and offline is considerable. The most common forms are JPG and PNG, but there will also be formats such as SVG and the mysterious WebP. Users viewing photos on their devices may typically encounter the former or its twin brother - JPEG.

Apple hardware users may also have to deal with HEIC or HEIF extensions, which are not supported by browsers. Photo processors, on the other hand, will still use different formats. In this paragraph, I will organise the knowledge of structures and, using simple examples, present the advantages and disadvantages of the various solutions and indicate which format to choose depending on the situation.

At the outset, let's note that on our devices, we sometimes get photos with a JPG extension and other times with a JPEG extension. Therefore, which format to choose? It is of no consequence whatsoever.

Both formats are the same, so why does anyone suggest otherwise? The difference is because early versions of Windows, which ran on the FAT-16 file system, allow the name to be stored in 12 characters in the 8.3 structure, i.e. 8 characters name, dot, 3 characters extension. While those days are long behind us, the notation remains, and both graphics programmes and native applications on phones save images with a JPG extension.

Everything is clear to you, and the next time you see a JPG and JPEG format, you will know that both forms are identical. Things get more complicated when dealing with JPEG 2000. This format is not used in web services, as the following information on its support by browsers confirms.

There are many advantages to this format - it offers both lossy and lossless compression, as well as much better image quality (which comes with a larger image size).

On the other hand, the graphics we add to our site should not be a manageable size. Still, also of relatively good quality, so the JPG format is better suited for this application.
 

The most significant difference between PNG and JPG formats is that the former supports transparency, while the latter has a much larger colour palette. It is also worth noting that the PNG format is only sometimes equal, and this is because we distinguish between PNG-8, PNG-24 and others.

What are those mysterious numbers at the end? This is the number of bits on which colour can be stored. This means that PNG-8 has a range of 256 colours, while PNG-24 is around 16.7 million.

Well, Bartek, which format should I choose, PNG-8 or PNG-24? As usual, the answer is 'it depends'. Imagine you have a graphic containing one or more colours. Therefore, saving the pictures in PNG-8 format will be sufficient, making the file size significantly smaller than PNG-24 at the same quality. Let's see what this looks like using an older Drupal logo of 175x200.

Differences between PNG-24 and PNG-8:

  • PNG-24 has slimmer edges due to a much broader colour palette, while the rest of the graphics are no different,
  • PNG-24 occupies 16KB, while PNG-8 occupies only 4KB.

Let's pay attention to what happens if our graphic is smaller, for example, 50x57:

The difference between PNG-24 and PNG-8 is still visible, but not as much as before. This leads us to conclude that where there are excellent graphics, where details are not so visible while keeping the number of colours low, PNG-8 may be a better option.

Let us examine another example:

Differences between PNG-24 and PNG-8:

  • PNG-24 has higher saturation. This can be seen by comparing the colours overlaid by the inscription.
  • The differences in slenderness and quality are negligible.
  • The size of PNG-24 is 287KB, while PNG-8 is 66KB.

You already know what JPG and PNG are. Let's now focus on when we use PNG and when we should choose JPG.

You should ask yourself:

  • whether your graphics need transparency and
  • how large the colour range is.

Let's compare two graphics with a resolution of 1920 x 1125:

As you can see, they do not differ in terms of quality. It could therefore be argued that whichever format I choose will still be good. Unfortunately, I have to deny it, as the file sizes are drastically different.

The JPG format takes up 369 KB, while PNG is a whopping 2.9MB. Why such a big difference? It is primarily related to the data recording algorithm itself. The most important thing for us is that with this type of graphic, we will choose the JPG format.

Now let's consider a graphic with limited colours, i.e. the Drupal logo from the previous examples at a size of 175x200.

Once again, there is no difference in quality. Let's look at how the file sizes look. For the JPG format, this is 20KB, while for the PNG-24 format, it is 16KB.

If the graphic should support transparency, we have no choice but to opt for the PNG format. It is worth noting that JPG graphics can be compressed, resulting in a smaller size at the expense of quality, while even slight compression can significantly reduce the size of a JPG file. However, we cannot do this with a PNG file.

At this point, I have good news for you because Google, in response to JPG and PNG, has created its own format: WebP. It’s a format specifically designed for web graphics.

According to the website's official information on the WebP website, it offers lossless conversion, saving up to 26% in size compared to the PNG format and up to 34% in size compared to the JPG format. In addition, this format also supports transparency. We can conclude that WebP is, in terms of functionality, somewhat of a combination of the JPG and PNG formats, offering much smaller graphic sizes. So let's check which browsers, as of 10.12.2022 support this format.

As you can see, these are almost all the most popular browsers. It is worth pointing out that if the client requires the page to display correctly under IE11 and its lower versions, then, unfortunately, we cannot use this format. More information on WebP can be found here.

Lets us draw attention to one more important aspect: scalability. Websites have different-sized containers in which graphics are placed.
At a time when graphics should always look good - regardless of the device on which they are displayed - scalability is significant.

This raises the issue of what size graphic we should use. Let's assume that the graphic takes up the entire available width of the main container, whose maximum size is 1920px. Using a phone, on the other hand, the width of this graphic is 375px. So should we choose the full-size graphic and scale it down as necessary, or should we choose the smallest and scale it up?

In the first case, we will download more data on the mobile device than we need. In the second, on the other hand, the photo will be quite smaller and, as it scales upwards, it will lose quality. This is because both JPG and PNG formats are raster graphics, meaning only a specific colour is assigned to each pixel. When the original width of the graphic is 375px, and we artificially enlarge it to a width of 1920px, we will create 'empty pixels', which will affect the quality of the image. The following examples illustrate the situation at hand.

When comparing graphics, pay particular attention to the foreground. As you can probably see, the edges are not slim, and the photo looks jagged and out of focus.

We will discuss dealing with this problem in later sections of this article, as it involves using appropriate HTML codes. At this stage, the most important thing is knowing that such a problem may occur.

Another popular format used on the web is the SVG format. The lack of quality loss characterises it during scaling due to how the graphics are represented. The SVG format belongs to what is known as vector graphics and is described by geometric figures and fields delineated by curves that constrain its shape. This needs specific mathematical formulas that realise these tasks.

When is it worth using the SVG format?

  • where the graphic contains several colours, and the background is transparent, this format can provide an alternative to the PNG format,
  • when we want to use CSS and JavaScript to animate it,
  • particularly when dealing with icons.

On https://www.magneticpoint.com/ we have made extensive use of this file format. Below I show the top of the homepage with the highlighted graphics, which are SVG files.

You already know which graphic formats you are most likely to find on the web and the advantages and disadvantages of each solution. Below is a table summarising the most important aspects of the formats discussed.

Format Lossy compression Lossless compression Vector graphics Transparency
JPG X X    
PNG   X   X
WebP X X   X
SVG   X X X

 

Another vital aspect to pay attention to is identifying the location of our website's target audience. This will help us to estimate which devices are most commonly used in the regions, their manufacturers and operating systems. This directly impacts how the various graphic resolutions should be prepared. Before I go into the details, I would like to present some statistics.

(source: https://gs.statcounter.com/os-market-share/mobile/europe/#monthly-202210-202211-map)

In the graphic above, we can see that in Europe, Android systems still dominate the majority of the market. Only individual countries have a higher number of iOS users. To begin with, let's assume that we want to design our system for Polish users, so let's see what the statistics of operating systems used in this country look like.

(source: https://gs.statcounter.com/)

Based on the statistics presented, most of the population likely uses mobile devices, where 52.95% are Android users, and 7.81% are iOS users.
In contrast, 35.63% of users use Windows. Unfortunately, we cannot determine whether these people use mobile devices with this system or are mainly using desktop devices. Therefore, let us check which operating systems are used exclusively by mobile devices in Poland.

(source: https://gs.statcounter.com/)

As we can see, the market is dominated by Android mobile devices, while iOS accounts for 12.84%. Windows only accounts for 0.07% here, which suggests that 35.63% of users use it on desktop devices.

At the very end, let's check the situation with the browsers.

(source: https://gs.statcounter.com/)

Chrome is the clear leader at 58.9%, followed by Safari at 21.21%. The remaining browsers range from 3-6%.

At this stage, we can draw the following conclusions for Poland:

  • Approximately 60% of the population mainly uses mobile devices.
  • Android operating systems have a clear advantage, at around 53%.
  • The most used browser is Google Chrome, with 58.9%, followed by Safari at around 21%.

At this point, you may be wondering why we need all this information - after all, we just want to prepare some graphics for our service. With the data discussed, we know precisely which devices our pictures should be optimised for.

Thanks to the statistics above, we know that around 20% of people use Apple products and, as you may have heard, these products use Retina displays. With these, we get significantly better image quality. Where does this 'better' image quality come from? At this point, we need to use the PPI, or pixel per inch. As the name suggests, it determines how many pixels per screen per inch.

Retina displays use the proverbial 'higher pixel density per inch'. Depending on the equipment model, this can be 2x or even 3x. What do these data mean in practice? Namely, when you have a standard 1920x1080 image, it will be 'treated' by the Retina displays as if it were twice the width of a 2x, i.e. 960x540. As you can see, this can be quite a problem. If the images on the page are to be displayed in their original form, you should see them twice as small on Retina displays.

On the other hand, if the programmer has chosen to have the graphic always occupy 100% of the width, scaling up will occur, and the image will lose quality, as you may have already seen in a previous paragraph. I have presented this case below.

Does this mean that you should prepare graphics for each display? Or just make them big enough, e.g. 600x600, and both on a Retina display with a PPI of 2x, and on 300x300, they will look great because we will scale them down?

Of course, this is one solution, but remember that we are discussing optimising our graphics here. For example, delivering a 600x600 illustration to a device that displays it at 300x300 will unnecessarily cause the browser to load 2x more data than it should. So what is the solution to this problem? From a content editor's point of view, there is little we can do when the site is not prepared correctly and cannot 'decide' on its own what graphics it should deliver according to PPI.

This is done automatically using Drupal, among other systems, and preparing the template accordingly. You will see this in the third article on optimising website graphics. But before we get to that, I'll show you what tools you can use to optimise your pictures. We will also delve deeper into the HTML code so that I can show you how the whole mechanism works.

In the first part of this article, I introduced you to the essence of the graphical optimisation problem. Then, we moved from the topic of the devices we should consider to identifying graphics on websites that should be reduced in size. In turn, we discussed the most popular formats with their differences and when to choose which. In addition, I have presented a considerable amount of statistical data based on which it is possible to decide for which devices the graphics should be optimised according to the region in which the website will be used. At the very end, I discussed the problem of presenting pictures to users using different displays.

I will show the various tools and optimisation techniques in the following article. I will also offer code snippets so that you know how to 'tell' your browser to load the appropriate graphics depending on the detected PPI.