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.
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 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.
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.
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.
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:
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:
- GUI apps,
- CLI tool,
- node.js library,
- or GULP and GRUNT versions
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
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
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 |
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.