I’ve been considering moving to using WebP images on this site. It’s a new format developed by Google, and it has a couple of advantages over the venerable JPEG. It’s royalty free, it provides more efficient compression, and it supports all the good things like alpha transparency, special encoding profiles, animation, and lossless encoding.
The general rule used to be that you’d choose each image format based on their particular features. For photos you use JPEGs, for diagrams/cartoons you use PNGs, and if you need simple animation you use a GIF. Well, now with WebP there’s a single format which covers all those use cases. It’s also got decent browser support, at least since it finally got support in Firefox this time last year.
Here’s a simple test to see if your browser can show WebP images.
And now we see that WebP is supported by most browsers, except for Safari. Is this a problem? About 6-7% of people who end up here use Safari, and I can’t just ignore those readers.
Although, if you are reading this on a Macbook, I’m afraid your default browser is obsolete, why not try an alternative?
I’ve done a comparison of the main image formats, starting with a photo I took in Mallorca as my reference image.
|Format||Conversion time||File size||Output|
PNG and GIF files are evidently unsuitable, although I like the low-tech aesthetic of dithered gifs.
For both JPEG and WebP I used a quality setting of 70. You can see that WebP takes slightly longer to encode, but results in with a smaller file size by about a third. At a quality setting of 70 they both look basically identical, I can’t see any significant differences.
So, let’s drop the quality all the way down to
25 10, and get some real knarly compression artefacts. I want to see those 8x8 blocks and off-colour blotches spreading across the picture. It’s still the case that compression artefacts are irritating, but as with dithered gifs, if you subject an image to enough degradation it starts to cross over into art.
Zoom into the apartments on the right hand side of the road, near the centre of the frame. Here’s that area with some brutal JPEG compression.
And here’s the same section of the image with the same WebP compression (and then reconverted into JPEG for the sake of compatibility).
This is a much clearer visual comparison, you can see that the colours in the WebP example are still washed-out and blurry, but that’s almost nothing compared to the obvious degradation of the JPEG.
Going back to the problem of Safari, while it doesn’t support a lot of
popular media formats, it does have one unique standout feature. It supports JPEG 2000! The technically-superior JPEG format which inexplicably never caught on for widespread use.
How superior is it? Going off my reference image, at the same quality setting of 70, the conversion took 0.094s and produced a slightly larger 154.5 KB file. Not a massively impressive result.
Here’s a test, if you have this page open in Safari (edit: and Firefox!) then you’ll see a JPEG 2000 image below. However as of writing this, if you’re using almost any other browser the test will fail.
It still bothers me that images in this site’s feed look way too big in my RSS reader. Here I can limit the max image width with CSS, but the proper thing would be to… just have smaller images.
There are plugins for Jekyll which will generate responsive images. At build time you automatically convert all images to multiple formats and resolutions, so you end up with small WebP images, and different JPEG sizes as a fallback.
Unfortunately I’ve already compressed most of the images I use here, and the originals are a disorganised mess. No matter how I try and square it, if you want responsive images there’s a tradeoff in terms of added complexity.
Storing original images also introduces a space concern. I can accept paying for another 64GB SD card once the one in my camera fills up, but when it comes to storing this site on AWS servers, I’m happy that the whole thing currently takes up less than a gigabyte.
So long as you can’t see WebP images in Safari, it doesn’t make sense to use them here. However, if that situation changes then I suspect JPEGs are on their way out.