Image optimisation for the web

Written by Ramón Saquete

If we want our website to be profitable, it’s imperative that it has a good performance. To give you an idea, whenever Amazon decreases its loading time in 100ms, its revenue goes up by 1%, which brings them considerable sums of money.

There are many aspects we can optimise to lower our download speed, but the two most important ones are the database and images. In this post I am going to talk about image optimisation for content editors, designers and SEOs. There are other techniques, which developers, layout designers and system administrators can apply, but we won’t be tackling those today.

Images usually account for 70% to 90% of the information an Internet browser has to download to display a page. It is vital for the website that its content editors know how to reduce the weight of images, without losing quality. Keep in mind that, albeit they make download times worse, images are there to attract attention, which is why good photography in an online shop or any other website, is important. But pictures must also load fast and look good, in order to try and increase the revenue obtained through our web page.

But before getting into the specifics, let’s review some basics:

Basic concepts

• Difference between lossless compression and lossy compression. When we compress an image and it loses quality in the process, we are using a lossy compression. If, on the contrary, the compressed image remains identical to the original, we are using lossless compression.
• Raw format. In a computer, a raw image file means it hasn’t been compressed, and it contains the exact information the computer needs to display it on screen. In photography, raw format means something different, as the image is stored exactly as it is picked up by the sensor (although it’s not usually entirely raw, since cameras apply lossless compression).
• Pixel. Images displayed on a computer screen are composed of a grid of points, called pixels. Each pixel has a numerical value associated to it, indicating which colour the monitor must represent.
• Colour depth or number of bits. If we take the width and height of the image as X and Y axis, its colour would be Z (depth), given that the colour is just another numerical value. If we say that pixels of an image can represent 8-bit colours, this will mean that each pixel can have any value between 0 and 255, as 256 is the number of different colours we can represent with 8 bits (2⁸=256). The colour depth used by a typical monitor is of 24 bits, and as a result, that is the maximum number these image formats usually have.
• Image size. The higher is the number of bits and the size of the image, the heavier its weight. Think about a 100×100 px image. If each pixel weighs 1 byte (8-bit colour depth), then our raw image will weigh 100*100=10,000 bytes = 9.76KBi. But, if instead of 8 bits we have 24 bits, each pixel of our image will weigh 3 bytes, and the full image will be three times heavier, 30,000 bytes = 29.29KBi.

Now that we are familiar with the very basics, let’s see the different formats we can use to store our images, and which we should use at different points in time. It doesn’t matter whether you use Gimp, Adobe Photoshop, Adobe Lightroom or Corel Photopaint, everything I am going to explain here is equally applicable to any photo editing software of your choice.

JPG (Joint Photographic Experts Group)

JPG is a lossy compression format supporting a 24-bit colour depth. It doesn’t support animations or transparencies. It’s the ideal format for colour or black and white photographs, especially if they have a great range of colour shades. When saving images of this type, we must adjust the quality level between 0% and 100%. The higher this value is, the heavier will be the image’s weight, meaning the quality loss will be less noticeable. Usually, at 70-80% we won’t perceive any difference between the original image and the compressed one, as the compression applied to it is based on statistical studies of human vision. In some programs, you can choose the sub-sampling of the image colour. We will choose the sub-sampling option that reduces the image the most, 4:2:0 or 2×2 1×1 1×1. With this option we will reduce the colour information the image contains, and we won’t notice any difference. If it’s a black and white image, all colour information can be removed with 4:0:0, but this is something software usually does automatically.

PNG-24 (Portable Network Graphics)

32-bit lossless compression format. Out of these 32 bits, 24 are used to represent colours, and 8 to create transparencies with various opacity levels in each pixel. It doesn’t support animation. If we use it without transparency, it will only use the 24 bits per its name.

This format should be used only when it’s absolutely necessary to use images with transparencies. If the background below the image isn’t going to move or we don’t intend to use the same image with a different background, it is preferable to paste the website’s background, and save the image in a different format. Given that it uses the highest amount of bits per pixel and lossless compression, PNG-24 format is the one that weighs the most.

In some programs we can adjust the level of compression from 0 to 9, with 9 being the value that will make the file less heavy, and which we should always choose, as the image quality won’t suffer, regardless of the chosen compression value.

PNG-8

Just as PNG-24, it uses the same lossless compression algorithm, but with an 8-bit colour depth. It supports transparency, but not with different opacity levels. This means that if the transparent area has rounded borders, it will show us a saw tooth-like effect (although, in reality, the photo editing software is the one preventing us from saving images with different opacity levels, the format itself does allow it). It doesn’t support animation either.

8-bit colour depth image formats are also known as 8-bit palette or indexed colour formats. This is because each of the 256 colours is associated in an index to one of the 16.777.216 colours that can be represented with 24 bits. This means we have a limited 256-colour palette, which were previously selected from the 16 million available ones.

This format is ideal for drawings, icons, logos, designs, and in general, any image with a small amount of colours. We will preferably use PNG-8 over JPG for this type of graphics, because if we use JPG we will notice its algorithm’s lossy compression effects, as the image will look as if it has been applied some sort of perceptual blur. In a graphic with well-defined borders it will be much more noticeable than in a photograph. Moreover, with JPG we won’t accomplish such a high compression effect as the one provided by PNG for this kind of images, because it compresses better when the same colour is used repeatedly.

If an image has more than 256 colours, we can save it in PNG-8 all the same, but to do this we need to reduce its colours beforehand. Our software will allow us to choose some type of dithering technique. Each will distribute, in its own different way, the pixels of a colour surrounding the pixels of another colour, to give off the appearance that there’s an intermediate colour in between the two. Dither, albeit it requires some loss of information, allows us to use this format with images slightly exceeding 256 colours, without making its lossiness too apparent.

If an image has less than 256 colours, o we want to reduce them in number to reduce its weight, we can specify this to our program. Thus, we will have images with the following ratios between the number of bits and colours: 1 bit = 2 colours, 2 bits = 4 colours, 3 bits = 8 colours, 4 bits = 16 colours, 5 bits = 32 colours, 6 bits = 64 colours, and 7 bits = 128 colours.

The biggest issue with PNG-8 and PNG-24 is that the gamma correction applied to colours prevents us from being able to create images so that they have the same colours as other elements from a website in all Internet browsers.

GIF (Graphics Interchange Format)

Just as PNG-8, GIF has 8 bits, it’s lossless, and allows transparency without different opacity levels. As opposed to PNG, colours are not applied any gamma correction. Its main feature is that it’s the only format allowing animations that is supported by all browsers.

It must be used just as PNG-8, for graphics with fewer colours, but only when the images have very few pixels, or we want to maintain the chromatic ratio with other colours on the website. In other cases, PNG-8 is better because it achieves smaller file sizes.

This format was very popular in the early days of the web for animations. Here’s an interesting fact: this format’s creators inadvertently used a patented algorithm, which resulted in having to pay a license for posting GIF files on your website from 1994 to 2004, which gave rise to a campaign against this format, called burn all gifs.

WEBP

This format was created by Google to replace all others up until that point. The problem is, it is only compatible with Chrome and Opera internet browsers, besides there being very few tools available to open it. It’s a 24-bit format, it can be used for both lossless and lossy compression, it supports transparencies with various transparency levels and animations. The only thing it doesn’t support is the 8-bit indexed colour, so it wins over JPG in terms of quality and picture compression, but in image graphics with little colours PNG-8 still prevails. Its use is not recommended, in any case, due to the little support it receives.

A few general recommendations to finish this post

• Never store images with larger dimensions than the spot in which they are going to appear.
• Always save images in a progressive mode if it’s a JPG, and in an interlaced mode if it’s a GIF or PNG. This option allows the image to appear in full while it is loading, but at a lower resolution, which will go on becoming more detailed as it continues to load, even though it’ll make the file slightly heavier, instead of loading line by line or bit by bit. The user will perceive that the image is loaded earlier, and all engineers know that in any user interface perceived speed is always more important than the real speed, which is why we have the toolbar creating the effect that these tasks take less to load, when in reality, they are taking a little longer.

• Do not store, and even remove –if possible– any text fields provided by image formats for meta information. This data is irrelevant, containing information like creation date, EXIF data with the camera parameters used to take the picture, etc. It is recommended, though, to fill in the comment field with keywords describing the image, as Googlebot can read them.
• Write your image file names as you would SEO-friendly URLs: no accent marks, no special letters, and with hyphens instead of white spaces.
• Always write an alternative text when inserting an image into the HTML code (“alt” attribute).

And these are my recommendations. When in doubt, the best thing to do is to save the image in several formats and keep the least heavy and better looking one.