![]() ![]() 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! 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.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. 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.Well, it turned out, that both of these modules implemented the WebP support without making WebP the real new number one format: So why should we duplicate any image style? On the surface, there seem to be no problems, there are 2 contributed modules with a solution for this: WebP and Image Optimize WebP. 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. You can implement fallback to JPEG with Drupal core however, all of your image styles will need to be duplicated. 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.īefore going down this route please also consider that your image styles folder will require almost twice as much disk space. I recommend using dedicated image styles for newsletters. For newsletters or email marketing, you still might consider using JPGs.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.I believe this is an edge case.If you have animGIFs, then these should simply be handled with dedicated image styles. Animated GIFs are a separate story as animated WebP is not supported that much yet.In our experience setting the WebP quality to 80% produces the optimal image size and quality. 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. At the moment of writing this post, there is no way to set the quality of Webp with GD or Imagick in core.If JPEG support can be dropped, which means Internet Explorer users and older Safari 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: 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. 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. Let’s save some baby seals!Īs common implementation issues arose the complexity increased until I wished I had postponed implementing WebP by another year. 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. 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. As we focus solely on Drupal and the tools widely available for Drupal all use libjpeg, we did not verify this. The official study from Google compared the original JPEG algorithm with WebP, while there are improved JPEG implementations such as the MOZJpeg.For such edge cases, you should consider using a separate image style or even the SVG format. ![]() ![]() WebP shines for photos primarily which I believe are the vast majority of uploaded images.
0 Comments
Leave a Reply. |