WebP - The Right Way and The Wrong Way in Drupal

What is WebP and what are the benefits?

WebP is the most supported next-generation image format. The average WebP file size is 25%-34% smaller compared to JPEG file size at similar quality. WebP offers all key features, that until now have only been available only through a variety of image formats, such as:

JPEG - fairly good quality lossy compression
PNG - transparency, lossless compression
GIF - animation (animated WebPs are not that much supported at the moment, but this is also growing)

Official page: https://developers.google.com/speed/webp

Official study about quality: https://developers.google.com/speed/webp/docs/webp_study

Drawbacks?

One comment regarding WebP lossy quality vs jpeg: if you have abstract images with precise geometric graphics JPEG may still perform better (this is a subjective observation, check your images for example with this great tool: https://squoosh.app/). WebP shines for photos primarily which I believe are the vast majority of uploaded images. For such edge cases, you should consider using a separate image style or even the SVG format.
The official study from Google compared the original JPEG algorithm with WebP, while there are improved JPEG implementations such as the MOZJpeg: https://siipo.la/blog/is-webp-really-better-than-jpeg. As we focus solely on Drupal and the tools widely available for Drupal all use libjpeg, we did not verify this.

What could go wrong?

When I read that WebP is officially supported in Drupal core (it has been included since Drupal 9.2) I asked my team to roll it out to our projects. I was hoping for a drop-in replacement without any issues, basically, a quick win in Lighthouse reports resulting in a smaller footprint for the webpages. Let’s save some baby seals!

As common implementation issues arose the complexity increased until I wished I had postponed implementing WebP by another year. I remember the moment when we started to see WebP images in our projects with worse quality than previously with JPEGs, while their size wasn’t even smaller that much. Spoiler: the poor quality and size wasn’t caused by the WebP image format, but rather due to an incorrect implementation approach on the Drupal side, in contributed modules.

Do you need JPEG support as a fallback?

If JPEG support can be dropped, which means Internet Explorer (not supported by Microsoft since June 15, 2022) users and older Safari (<2021) users won’t see images, you can stay on the safe side by simply adding the core WebP conversion (“Convert WEBP”) to your Image Styles and it’s done - with only a few small comments to bear in mind:

At the moment of writing this post, there is no way to set the quality of Webp with GD or Imagick in core. If you are not satisfied with the quality or the size of the generated WebPs, then ImageMagick (the command line tool) ought to be utilized. In our experience setting the WebP quality to 80% produces the optimal image size and quality.
Animated GIFs are a separate story as animated WebP is not supported that much yet. I believe this is an edge case.If you have animGIFs, then these should simply be handled with dedicated image styles.
Linkedin and some other social networks may not support Webp, so please make sure you use a separate image style with jpg for the og:image.
For newsletters or email marketing, you still might consider using JPGs: https://www.caniemail.com/features/image-webp/. I recommend using dedicated image styles for newsletters.

If your site requires support for Internet Explorer or older Safari browsers (WebP came with MacOS 11 in September 2020), you will need JPEGs as fallback images.

Before going down this route please also consider that your image styles folder will require almost twice as much disk space.

You can implement fallback to JPEG with Drupal core; however, all of your image styles will need to be duplicated. If you don’t have too many image styles, or they are not expected to be changed often, I would strongly recommend staying with core. On the surface, there seem to be no problems, there are 2 contributed modules with a solution for this: WebP and Image Optimize WebP. So why should we duplicate any image style?

Well, it turned out, that both of these modules implemented the WebP support without making WebP the real new number one format:

The primary problem is that they don't create the WebP derivative directly from the source file, but they are first creating a JPEG (or sometimes PNG or GIF according to the original file's format) and then converting it to a WebP. As the image styles are downscaled in most cases and the JPEG lossy compression is applied, the potential quality and/or size benefits of moving to the WebP format this way are essentially wasted.
Another issue, a performance-related one, we've seen is that they are creating the JPEG and the WebP derivatives at the same, single request for the WebP image. We believe that a request for a WebP image should not generate a JPEG - the vast majority of browsers are supporting WebP, maybe that JPEG will never even be used!

I don’t feel right blaming these modules, because I know that they are created with lots of effort and they try to give recommendations for better image quality. With that said, as it is very easy to end up with a poor implementation I had to raise attention to this. In the meantime, we’ve created a helper module to overcome the primary issue: WPF.

Summary comparison table

https://docs.google.com/spreadsheets/d/1nZXNfxIpLijlCWca6ttlnMTzMqPIeBSlz1I7rgfFyCM/edit#gid=0

WebP related issues and contributions by BRAINSUM

Conclusion

I believe WebP serves as a convincing replacement for JPEG. For new projects, I would consider using it as the default image format of image styles except for the style used for social sharing and newsletters. For existing sites, I would not urge anyone to rush into it, even though there is a safe fallback to the JPEG approach.

If you decide to go for WebP try to stick with Drupal core’s support and ImageMagick (CLI) as the current mainstream contributed modules do not treat WebP as the new default format; therefore, its potential is not fully harnessed. With Drupal 10 dropping support for Internet Explorer in December 2022, a strong argument will arise to no longer implement fallback to JPEG. Until that time, or if you really need to support older Safaris you can use Drupal core’s Convert to WEBP plus WPF.

Check your image quality and size before committing yourself to being done - it is nice to get rid of one warning in Lighthouse, but it should bring real benefits.

The cost of managing complexity should also be considered as new challengers come about such as AVIF and JPEG XL.