How much difference does WebP actually make?

WebP as Google puts it is “a modern image format that provides superior lossless and lossy compression for images on the web.” If you undertake regular website testing you have probably also seen it recommend by Googles Page Speed Insights tool among others.

I wanted to illustrate the difference it makes to our websites speed and bandwidth usage. Therefore I have created a couple of example pages to run tests on so we can understand the differences in currently available image implementation techniques.

Disclaimer: This is not a guide on how to best implement WebP usage or how to convert your images to that format. If you’re after that information there are detailed articles on CSS-Tricks and Smashing Magazine which do excellent jobs of explaining things.

With that out of the way lets take a look at the setup. We have 3 very simple pages on a WordPress website with the same 10 images on each page to keep things fair. On our first page we have a simple image gallery with no optimisation added at all. These images have been upload straight into WordPress and I have deliberately used only the src attribute in the template file. This approach is going to give us our baseline for worst case implementation.

I intend to test each page with a desktop and mobile view via the Firefox dev tools and note the average page load time from 3 tests with the cache disabled. I am measuring the page load time relative to the data weight of the images. Additionally I will assess the difference in times from throttling limits based on 3G, 4G and my home fibre connection. Perhaps not the most scientific test setup, but it should be sufficient to illustrate the differences in the approaches for image implementation.

Desktop results for the first page: A simple image gallery with no optimisation

I am only using the src attribute in this first example so there’s no difference in setup between desktop and mobile views. Therefore running an additional mobile test here would be pointless. So lets assess these results straight away.

They’re bad. Very bad. 3.87 seconds on desktop non throttled isn’t ideal at the best of times. Our target is 2 seconds, anything slower than that and it’s likely going to be detrimental to our bounce rate. For the visitors on 4G and 3G the results are unacceptable. Very few are likely to wait that long for a web page to load, and if they do it’s going to be ruining their experience.

So how can we improve this?

Typically I would recommend outputting your image assets no larger than they are required to be on your website, wherever they may be situated. Though take into account retina displays, and look to reduce file sizes with image compression via your editing software where possible. However for these tests I’m focused on purely technical implementations, so we will stick to those only for now.

The simplest implementation is with the srcset attribute. The srcset attribute is helpful because it lets us specify a range of image variants (different image sources) to be used at different viewport sizes. This is great, but has a slight catch, in that the browser makes the decisions on which images to used based on a couple of different factors. However for the most part it delivers what you would expect. So we can have one image at desktop screen sizes with larger dimensions, and another for mobile screens with much smaller dimensions. In reality we can have as many variations as we want for a variety of viewports, however in the interests of keeping this focused on the practical this basic setup is enough.

The main benefit of this approach is images that are tailored to the target viewport resolutions, and this reduces our image file size. So in theory it will speed up our page load times. Let’s test it.

Desktop results for the second page: Scaling the images correctly with srcset

Mobile results for the second page: Scaling the images correctly with srcset

As the results show, using the srcset attribute and defining key viewport sizes for variations of our images makes a significant difference in page load times compared to our baseline. For non throttled results we’re seeing load times of sub 2 seconds, but more importantly we’re seeing this on our 4G mobile connections now as well. Although our 3G connections are still lagging behind. On 3G desktop it’s worse due to the larger image sizes being requested.

So it’s an improvement, but let’s see if we can do better with WebP converted images and understand their importance.

Desktop results for the third page: Compressing the images further with WebP

Mobile results for the third page: Compressing the images further with WebP

As the results show, utilising WebP gives us another clear improvement against all our previous results. This is mainly thanks to the reductions in file size whilst maintaining our image quality. On desktop we managed to drop our image file size by 37%, and on mobile it was 36%. So WebP is giving us a pretty consistent reduction in file size, and making our page load times fairly respectable. While we’re not sub 2 seconds on mobile 3G, we’ve more than halved the load times to 2.78 seconds. A distinct improvement.

This was a very basic exercise with some simple examples, but in conclusion we can see the real importance in optimising the images used on your website. At a minimum I would suggest employing techniques for responsive images with the srcset attribute. With some careful planning and consideration you can significantly improve page load times and file sizes. However if you can convert your images to WebP and implement them, then there are good gains to be had. It may seem insignificant chasing after small gains measured in milliseconds but it makes all the difference to your customers when their browsing your website. You can find extensive information regarding the subject on Google’s Developer Platform.

I hope you have found this little test insightful, and if you have any questions about optimising the images on your website please feel free to get in touch.