Do not generate WebP unless "Display images in Next-Gen on this site" is enabled

[blogtutor]

Describe the bug Version 2.2 now generates WebP versions automatically, with no apparent way to disable it.

To Reproduce Upload a JPG. It will optimize the image and create WebP images as well.

Expected behavior Imagify should not generate WebP if "Display images in Next-Gen" is disabled.

Screenshots

Settings:

Images on the server after upload/optimization:

Additional context Related forum post here: https://wordpress.org/support/topic/disable-generating-webp/

We do not want to generate WebP images. It seems really bizarre that version 2.2 now always generates WebP even when “Display images in Next-Gen Format” is not enabled (since the files won't be used anyway), but in our testing, that’s what’s now happening in 2.2.

We do not want WebP (nor AVIF), as we prefer to stick with PNG/JPG and then Cloudflare Polish. Generating the additional format images uses a lot of extra space, which increases hosting costs for our clients and makes backups/restores even more difficult and expensive for us.

[Nations112]

I hope you will return this option. It is absolute nonsense to always have this feature active. Many sites use imagify to optimize images and not use webp. Some templates generate over 10 thumbnails. so one picture suddenly has 20 variants and it’s really unbearable. If the webp/avif display function on the web is disabled, it makes no sense to generate them. We optimize the images and saved size is then taken by webp?... You are primarily an optimization plugin, not a webp generator plugin.

[markonikolic985]

Hey 👋

You can use the following code to skip generating WebP files:

add_filter( 'imagify_nextgen_images_formats', function( $formats ) {
    if ( isset( $formats['webp'] ) ) {
        unset( $formats['webp'] );
    }

    return $formats;
} );

[blogtutor]

Thanks @markonikolic985 !

We're trying to figure out the best way to proceed. We very much do NOT want automatic WebP generation, as it will double the number of files on the server, and they won't ever be used.

Is the Imagify team still considering reverting this change (and not requiring a filter)?

[blogtutor]

@markonikolic985 Thanks for creating the helper plugin. But WebP generation should not be an automatic, behind-the-scenes thing. Especially not when it's completely hidden from the user's view! Site owners won't even know these files exist. And if Imagify isn't even configured to serve them, it's a total waste of resources.

We are a longtime user of Imagify (and WP Rocket), and support and maintain hundreds of publisher sites - from smaller sites to some of the largest blogs (some in the 30+ million pageviews/month range). We deal with backups and disk space issues daily.

I was one of the most vocal critics when the Performance Team tried to get this into Core:

https://make.wordpress.org/core/2022/03/28/enabling-webp-by-default/ https://make.wordpress.org/core/2022/04/12/follow-up-on-webp-by-default-proposal/ https://core.trac.wordpress.org/ticket/55443

It's going to create twice as many files on the server, using up a tremendous amount of storage space. This will cause people to have to spend more for hosting, and it will make backups take longer and also require more storage space for those (and restores will be more challenging too.)

We're going to block this for our clients, so it won't cause problems for us -- but really, we shouldn't even have to do that...and those people who use Imagify but don't have the benefit of us looking out for them are likely to going to have problems in the future.

Please reconsider this decision.

[CostaC]

Agreed with OP. This should not be a silent background "feature".

I don't get what the devs need to brainstorm? Just add back the "Create webp" checkbox and let us choose! You are over-thinking this by trying to "make is simpler".

And please do not go the Wprocket method and force us to install a 6-line "helper" plugin on all our websites. We manage over 200 websites and that would be a ridiculous fix.