Jakub Skala10.7.2019Back

Tweaking for performance: Optimising Images

As you’re optimising the performance of your website, sooner or later you’ll ask yourself the question: "So how about the pics? Are they OK?” The following text will help you get your head around this challenge.

Number one: choose the right format for your images. Not much has changed over the last few years when it comes to formats. The following rules still apply:

  • JPEG is good for photographs, i.e. images containing a large number of details that the human eye might overlook easily.

  • PNG is good for screenshots, i.e. images with sharp edges, solid spaces of various colours, and it supports transparency as a bonus.

The only new thing released in the last decade is SVG. It’s a vector format particularly good for charts, logos and icons. SVG also makes it possible to take a JPEG image and add transparency using a cropping mask.

New formats

Only Google has been able to stir up the still waters of image formats with its WebP format, but despite relatively broad browser support, this format hasn’t really taken off much.

The WebP format derives from VP8 video codec, but even that codec has been replaced by newer and more efficient ones: VP9 and H265 (HEVC). WebP is -in fact- a single frame from a VP8 video, and there are more advanced video formats, as far as we know. What you can do is try this little hack:

Compose a video containing nothing but a single frame and insert a photograph in it. This gives you a much better compression than any current image formats. If the video doesn’t support new video codec, the fallback that shows will be an image from the poster attribute.

Example 1: Live test of video codecs for still images

The above sample also uses the latest AV1 video codec. All major browser companies took part in the design of AV1, which is why quick adoption is expected.

Just as WebP is based on VP8 codec, so will AV1 have its image equivalent designated under AVIF (Windows users can try it out already).

Progressivity

Progressive images or interlaced ones in case of PNG are one of the most important properties of image formats.

The human eye is not perfect. The brain tries to make up for it and so it completes the contents of an image from just a hint of contours and colours in a split second. You can use those powers of the brain to improve the perception of how fast they are downloading.

Progressive images are not smaller (in fact, on the contrary, they contain more transitions in various details) but visitors to your site are able to figure out the content of the images, which has a dramatic impact on their perception of how fast the images are downloading.

Progressivity is what still gives JPEG an edge over WebP even though the latter consumes less data. Site users still perceive JPEG as faster despite consuming more data.

Example 2: Progressive JPEG live test - use provided controls to check the result

Placeholders

No matter how hard you try to optimise images and server connections, their download is always behind the page text download. These gradual downloads are disturbing for various reasons, which is why placeholders come to play.

Placeholders have a short life. They show for a few seconds max and then go to oblivion. They just come and go, so make them as little and as universal as possible to be able to use them throughout your website.

The most frequent thing is an SVG icon of the image or a “hypnotising” spinning wheel.

Example 3: Common placeholder examples

In an effort to minimise the disturbing factor for site users, very low-resolution and low-quality images are also used as placeholders.

This method is based on a principle similar to progressive image downloads, which is what makes it redundant. Instead of downloading extra reduced images or, in other words, data that are of no use later on, it is better to set up progressive image serving from the server. What happens is that the server first sends 10-20% of all the images on a page and then continues sending the rest instead of serving one image at a time. The progressive JPEG gives you a placeholder that shows a hint of an image, and doesn’t cost you a single byte more.

Lazy loading

The principle of lazy loading is simple: download images the moment you need them, saving bandwidth during the initial download.

If you don’t want the perception of download speeds to get worse, stick to the following principles:

  • Never apply lazy loading to images in the visible area above a page break.

  • Start the image downloads well in advance to make sure that fast-scrolling users and those on a slow connection don’t run into images that haven’t downloaded.

Figure 1: Lazy loading explained

The disadvantage of lazy-loading images is the independence from JavaScript, which makes the images invisible to search engines. The Google-recommended solution is to use the noscript element and to hide the image in it or you can also use the priority of scrset over src.

A new alternative to lazy loading without the undesired side-effects is Priority Hints. Browsers set the priority of all the assets being downloaded (css, js, img, iframe) and the server – if configured correctly – assigns higher or lower priority to individual assets.

As the web designer, you are better able to set the priority of individual assets. For example, you can assign a lower priority to an image even though it is higher up in the code. The easiest way to demonstrate it is on an image carousel:

Figure 2: Carousel and importance of images

The first two images have lower priority because they’ll be hidden after downloading styles and scripts and, on the contrary, the three middle images have high priority.

Optimisation

There is a number of libraries and tools to deal with the optimisation of image traffic. Luckily, there is a tool that integrates all those libraries: Imagemin.

There are several variations of Imagemin:

They all make it easy to integrate Imagemin into pretty much any project.

The volume of traffic you save depends on the library you decide to use. As we said before, Imagemin embraces a broad range of libraries, which allows you to use, for example, mozJPEG for JPGs or ECT for PNGs. It is common to achieve savings in the order of tens of per cent.

 

Image optimisation libraries compared

There are two images, a photograph (JPEG) and a screenshot (PNG). The bottom of each table gives you the result for Web – this is not an optimisation; it is more of a conversion into a different image format.

JPEG

JPEG testing image - a dog

 

Method Size Bandwidth savings Time to optimise
Original JPG 713kB 0% 0s
mozJpeg 206kB 71% 0.66ms
jpegoptim 704kB 1.3% 0.14s
jpegtran 703kB 1.4% 0.17s
guetzli
(not progressive)
515kB 26% 330s
WebP
(different format, not progressive)
96kB 86% 0.67s

PNG

PNG testing image

Method Size Bandwidth savings Time to optimise
Original PNG 259kB 0% 0s
ECT 179kB 30.9% 11s
pngcrush 209kB 29% 112s
zopfli 180kB 30.5% 248s
pngout 184kB 28.8% -
guetzli
(not progressive)
237kB 8.5% 448s
WebP
(different format, not progressive)
104kB 59% 1.1s

(Please note that images above are not the tested full-size images.)

To conclude…

If you want to run a real fast website, don’t forget to choose the right image formats, and their subsequent optimisations and prioritisations. If you don’t underestimate any of that, you can look forward to a substantial improvement to the user perception of how fast your website is loading.

Jakub Skala

senior front-end developer

Send Us a Message