As part of the set of measures we want to measure and use to comparison to know the real benefits of installing the plugin and enabling the modules, we need some sort of metrics as discussed on:

• Define a list of metrics that we need to measure #63

For new and existing images as described in:

• Create WebP images on upload #22
• Regenerate existing images #24

Storing the size of the image before the conversion would be helpful in order to run diff in size per image against the current image size and also an overall total in savings by using WebP images.

This can be done in all available image sizes as well in order to provide a better metric for the whole site instead. The ticket itself references the previous image size but it would be more accurate to store all previous image sizes available on the site before the conversion.

Coments:

Slightly related to:

• https://core.trac.wordpress.org/ticket/49412

Originally posted by @mitogh in https://github.com/WordPress/performance/discussions/83#discussioncomment-1941502

I know WordPress is about decisions not options, but I feel forcing image changes on websites without an easy way to opt out/in seems a bit heavy handed. Yes we are working towards a leaner internet, but forcing images to degrade (if that happens) or complicating the image loading experience for users will have a detrimental effect on adoption/continued usage of any platform.

I'd suggest keeping the original images as uploaded and processing the thumbnails with whatever format option is selected. If this option is ever changed then the thumbnails can be converted. User education is pretty clutch here as well.

Originally posted by @ecotechie in https://github.com/WordPress/performance/discussions/83#discussioncomment-1949235

I'm still in favor of the correct usage of the <picture> tag with <img> tags containing the correct srcset for both WebP and JPEG. The companies that I work with are far more concerned with keeping backwards compatibility and page size than disk space. Doing this would also allow for an additional image type as an early adoption eventually. The supported image types could be configurable in either a performance settings page or in wp-config.php as a single option. Any image clean up could be handled in WP CLI instead of on upload.

Originally posted by @zero4281 in https://github.com/WordPress/performance/discussions/83#discussioncomment-1949293

Removing old files seems a pretty bold move at these times. And even in the future.
The amount of storage should not be a concern (jpgs are small, webp even more).

Originally posted by @GoyWebdesign in https://github.com/WordPress/performance/discussions/83#discussioncomment-1949825

There are 3 possibilities then...

• Completely replace the uploaded image with a webp + generate webp resizes
• Keep a copy of the uploaded image and generate webp resizes
• Have a dual jpg/webp copy and serve the appropriate one to the client

I would prefer the second one, the support for webp is almost complete for all browsers and it doesn't make sense to keep a set of images that will remain unused. There's a chance that a small slice of browsers will be cut off but it's up to WordPress (since they do it on a large scale) to institute new standards that will force users to upgrade their browsers (but it's good since it's security and performance perspective)

Removing old files seems a pretty bold move at these times

I even think that the old (and maybe useless) resizes should be deleted, once all resize images are converted to webp.

Originally posted by @erikyo in https://github.com/WordPress/performance/discussions/83#discussioncomment-1955299

Links

• Store previous image size before WebP conversion #70
• #83