This is happening for any original image type: see #550 (comment)..

One thing I've noticed is that even when the imagify_keep_large_webp filter is set to false, the resulting stats displayed in the Media Library are not totally correct.

Here is an example image's stats after optimization, with imagify_keep_large_webp set to true, and we can see negative values for both the "Original Saving" and "Overall Saving" values:

If I optimize the same image with the imagify_keep_large_webp filter set to false, the WebPs are not created and the "Original Saving" value is correct, but the overall saving value is not correct. It's still a negative number despite the -scaled image and all the thumbs having reduced file size:

I cant understand how works Imagify compression algorithm, because when you use any other Image to WebP tool converter (eg: https://cloudconvert.com/jpg-to-webp), output WebP image is still lighter than original file, even with a high quality level. By sample, the WebP output image from my original image from #622 (3 Mb fullsized) is only 2.4 Mb (not 8.3 Mb like "compressed" by Imagify).

I've done a quick benchmark between 3 versions of the same light website:

• JPG: Imagify is enabled with "Normal" compression. WebP option is disabled
• WEPB: Imagify is enabled with "Normal" compression. WebP option is enabled and WebP images are displayed on website
  WEPB + PATCH: Imagify is enabled with "Normal" compression. WebP option is enabled and WebP images are displayed on website and I set the imagify_keep_large_webp filter to false.

Even if Google seems not really interested in any of these versions, enable WebP is definitively not a good solution for resources (space disk, bandwidth, energy consumption, ecology, planet…)

This issue (weight problem) is also related with a unresized/unscaled WebP image issue (size problem), see #521.

There is so much critical issues to deals WebP images with Imagify (feature implemented since 2019 but never really tested) so I will go back to ShortPixel (less buggy).

@piotrbak What do we want to do here exactly? We already have a filter to handle this case.

And the fact that some WebP images are larger than original ones is something that should be handle on the API side.

@Tabrisrp Here's what's supposed to happen in this PR:

1. The filter should be set to false by default.
2. Would it be possible to show a message here about the size problem with Webp?
   
   

Showing a message is complicated because each image and its thumbnails are processed individually, and the test for keeping the webp image is done for each, so you can have some that have it and some which don't.

Still having same problem. WebP pics are bigger than jpg's. (difference for me is about 3x)
I am using latest Imagify with latest WP Rocket. (webp turned on from wp rocket).

Since my investigation is still ongoing then I do not have full details jet

Files in server are small, but dev tools show that they are huge.

Update. Problem might have been in WP 6.7(.0) or the fact that srcSet didn't use webp images.. not sure, but it kinda fixed itself during optimizations round.