Create WebP images on upload

[adamsilverstein]

High-level feature:

• When uploading images to WordPress, the format for the sub-sized images WordPress creates should be WebP when available.
• When serving images in the frontend, use the WebP instead of the JPEG images

Overview

This is an overview of related issues. This may not necessarily be comprehensive, for a full list see all issues related to the "WebP Uploads" module here. When opening a new issue related to this feature, make sure to add the [Module] WebP Uploads label.

Key enhancements

Required for initial plugin release

• Create WebP module and port the applicable code #4
• When uploading, generate both WebP and jpeg format images by default #142
• Update the_content with the correct image format #149

Required for following plugin release and initial core patch

• Expose source_url for all additional mime types via REST API #167
• When generating WebPs, ensure full size is generated(-scaled for large images) #174
• Allow developers to tweak which image formats should be used #187
• When creating additional mime types use the original image instead of attached image. #204

Required for initial core patch merge

• Restore and backup Image sizes with sources when an image is edited #228
• Decide on order of webp_uploads_content_image_mimes filter items #237
• Allow controlling which image format sources in the frontend can be replaced #238
• Select the smaller image size from the list of available sources #186
• Ensure WebP/Image/Optimization plugins can integrate & use existing WebP images #160
• Ensure edited image sources are backed up when restoring the original image #295
• Enhance webp_uploads_pre_generate_additional_image_source filter to support returning filesize value #333

Exploration

• Image is partially converted to WebP #69
• Store previous image size before WebP conversion #70
• Investigate email client support for WebP, plugin usage #74
• Store previous image size before WebP conversion #96
• Progressive transition into WebP formats #150

Misc. bugs

• Image mime type is not set correctly when a webp image is generated. #67
• Ensure post meta reflects image mime type #75
• *.jpg is not generated for scaled full size image. #122
• WebP image are not rotated when uploading.  #146

Research

• Research: Impact of additional WebP images on upload #289
• Research: WebP compatibility #290

[BlogAid]

I'm very concerned with the auto change of format type on upload.

Many site owners are more concerned with quality than speed and want complete control over the compression type used - like photographers and artists.

And many other site owners do superior compression, with a modern file format like MozJpeg, prior to upload and also would not want their images to go through another compression just to change to a file format that gives them no extra benefit.

And it is possible to get a smaller file size with superior quality with MozJpeg compared to WebP on many images.

Plus, many hosts limit by inode, not disk space alone. And creating multiple image formats is going to increase the inode count.

This project sounds very much like a fork of the ShortPixel plugin - and choice about image format is not the business of WP.

It doesn't make WP faster - it makes the image load faster - and that's not the same thing.

There will be new and better formats in the future - then what?

[pbearne]

I suspect the ability to turn off WebP / fine-tune the image delivered could handle with filters that a plugin can hook into
If we create filters that allow fine gain control of the image quality we can your concerns
I can see the case to composed thumbnails(small images) but un compassed large versions in the same set of resizes

[bratvanov]

I'm also yet to see conclusive proof that WebP is better than JPEG when encoded with MozJPEG.
For some images, one will be slightly better than the other, and vice versa, but all within a very small margin to justify the extra added complexity of supporting a whole different format like WebP.

You also have to consider that AVIF is not the only major upcoming next generation image format.

There's also JPEG XL which by all indications will be superior to AVIF in every way, not just compression efficiency, but will especially excel for web use due to the various built-in responsive sizing features, progressive decoding, as well as having backwards compatibility with legacy JPEG for easier and lossless migrations.

AVIF, on the other hand is based on a video format, and while AV1 is a very good video format, this doesn't make the AVIF derivative a good image format. There's a significant difference in encoding priorities when each frame/image will only be seen for a fraction of a second (a standard video containing 24 frames each second). The AV1/AVIF encoder has to consider previous/next frames and motion in order to achieve the best video quality, and this context is completely irrelevant in the case of generating a single static image that will be used on the web.

Is WordPress eventually going to support:

1. JPEG
2. WebP
3. AVIF
4. JPEG XL

These are the 4 primary formats, and there's a lot of redundancy - WebP is not better than a properly encoded JPEG, yet WordPress is moving ahead with WebP support. And AVIF is not better than JPEG XL, yet there are indications that AVIF is in the roadmap for WordPress as well after WebP.

It's true that JPEG XL is slightly behind AVIF in terms of when it will be finished and adopted by web browsers, but it would be a mistake if WordPress commits to other inferior formats, and then when JPEG XL is finally ready, for it to be excluded due to there suddenly being too many formats to warrant "bloating" the core with yet another one.

So, will JPEG XL also be eventually planned for WordPress in the future? And if the answer is yes, what ramifications would there be in creating not just WebP, not just AVIF, but also JPEG XL images on upload? Would the core APIs be flexible enough to handle so many formats, and if not - would now be the time to reconsider exactly which formats will be supported?

[adamsilverstein]

Hi @BlogAid, thanks for the feedback. I'll reply to your points individually:

Many site owners are more concerned with quality than speed and want complete control over the compression type used - like photographers and artists.

Absolutely! Existing plugins, tools and approaches these sites use to optimize their images will continue to be supported.

And many other site owners do superior compression, with a modern file format like MozJpeg, prior to upload and also would not want their images to go through another compression just to change to a file format that gives them no extra benefit.

Can you explain a bit more about how you use MozJpeg and your workflow? Which images do you display on the front end of your site? In a typical setup, WordPress will (currently) create several sub sized images from the image you upload (using the same format as the upload). Unless maybe you have your theme set up to serve the original images instead of the sub sized images?

Typically, your upload gets compressed into several smaller sized jpegs with a quality setting that should work for most sites (and as filterable). Because WordPress is already re-compressing your images, it probably makes the most sense to upload the highest quality image you can. This change is only about the format used for these sub sized images, where the hope is WebP will provide the same quality, with a smaller file size. We are working on testing quality in https://core.trac.wordpress.org/ticket/54356.

And it is possible to get a smaller file size with superior quality with MozJpeg compared to WebP on many images.

I'm sure that is true. Unfortunately, MozJPEG is not supported by LibGD or Imagick - the libraries WordPress uses to generate sub-sized images.

Plus, many hosts limit by inode, not disk space alone. And creating multiple image formats is going to increase the inode count.

Good point that will more important for formats like AVIF where a fallback is required due to lack of strong browser support. For WebP we are simply swapping the format, so no additional files are created. In addition, disk space and bandwidth consumption should be reduced.

It doesn't make WP faster - it makes the image load faster - and that's not the same thing.

To clarify: the performance effort isn't just about making WordPress (wp-admin) faster, it is also about helping WordPress sites front ends in the wild perform better. Directly supporting modern image formats is a part of that.

There will be new and better formats in the future - then what?

We will continue to investigate enabling them for WordPress users when it helps them.

[adamsilverstein]

Hi @Euene - thanks for your feedback. I'll reply to your points individually:

I'm also yet to see conclusive proof that WebP is better than JPEG when encoded with MozJPEG.

I don't think using MozJPEG is supported in LibGD/PHP/Imagick so we can't leverage it. In fact, WebP is currently the best format widely supported by server backends.

There's also JPEG XL which by all indications will be superior to AVIF in every way, not just compression efficiency, but will especially excel for web use due to the various built-in responsive sizing features, progressive decoding, as well as having backwards compatibility with legacy JPEG for easier and lossless migrations.

Absolutely, JPEGXL does sound like an amazing new format! I haven't forgotten about it and we have this issue to track the idea: #12 which links to a trac ticket I believe you created :)

AVIF, on the other hand is based on a video format,

I wonder if this means it will be really good at encoding animated images (eg replacing GIFs)

Is WordPress eventually going to support JPEG WebP AVIF JPEG XL?

Based on the WebP ticket which took us over 6 years to land, I would say we will support these formats in core once they become widely available. That means nearly full browser support, and either good server support or a viable client based approach.

One way we can work towards supporting these formats is by for enabling enabling the picture element and improving core's sub-sized image generation to be capable generating sub sizes in more than one format.

So, will JPEG XL also be eventually planned for WordPress in the future?

JPEGXL support will depend ecosystem support as I mentioned above. Adopting WebP now and exploring AVIF next (which is supported in LibGD, Imagick and PHP) will only help set the stage for adopting JPEG XL

And if the answer is yes, what ramifications would there be in creating not just WebP, not just AVIF, but also JPEG XL images on upload?

I agree, you would probably choose one modern format (say JPEG XL) and one widely supported fallback (JPEG), not generate images in all possible formats.

Would the core APIs be flexible enough to handle so many formats, and if not - would now be the time to reconsider exactly which formats will be supported?

Exactly right - the API needs to be flexible enough to support new formats and fallbacks. The work we do landing WebP and potentially AVIF support lays a clear path for adopting additional modern formats like JPEG XL and does not exclude them.

[adamsilverstein]

I suspect the ability to turn off WebP / fine-tune the image delivered could handle with filters that a plugin can hook into

Hi @pbearne 👋🏼 🥂 ... yes absolutely, the change as proposed is simple to unhook/disable and we will document that in the release notes.

[bratvanov]

Thanks for your reply @adamsilverstein

I don't think using MozJPEG is supported in LibGD/PHP/Imagick so we can't leverage it. In fact, WebP is currently the best format widely supported by server backends.

My solution is to configure WP with the jpeg_quality filter set to 100. Then on the server side, a daily cronjob goes through wp-content/uploads and recursively optimizes all new images with custom-built jpegoptim compiled with MozJPEG. Yes, unfortunately it's not a solution that can be universally leveraged natively in WP core.

Absolutely, JPEGXL does sound like an amazing new format! I haven't forgotten about it

I'm glad that we agree!

I feel that AVIF steals a lot of the spotlight away from JPEG XL because people are very enthusiastic about the compression improvements that AVIF brings over legacy formats and that it has already shipped in some browsers and can theoretically be used today, but they aren't completely informed that JPEG XL has the same or even better compression in addition to the many other features that are lacking in AVIF.

I wonder if this means it will be really good at encoding animated images (eg replacing GIFs)

Yes, this is probably the one area where AVIF excels at and is better than JPEG XL.

I would say we will support these formats in core once they become widely available. That means nearly full browser support, and either good server support or a viable client based approach.

Great!

I agree, you would probably choose one modern format (say JPEG XL) and one widely supported fallback (JPEG), not generate images in all possible formats.

Yes, this eventually will be the ideal image stack. And we might not even need to store 2 separate files (JPEG XL and JPG) depending on the server implementation if I correctly understand the spec:

Migrating to JPEG XL reduces storage costs because servers can store a single JPEG XL file to serve both JPEG and JPEG XL clients. Existing JPEG files can be losslessly transcoded to JPEG XL, significantly reducing their size. These can be restored into the exact same JPEG file, ensuring backward compatibility with existing JPEG-based applications. This provides a smooth transition from legacy JPEG platforms to the modern JPEG XL. Both the transcoding and restoration are computationally efficient. Source

Coupled with the fact that multiple image sizes can be stored in the same file as well with JPEG XL, this should make for a very clean implementation where you need to store just one single file for legacy JPEG, next gen JPEG XL as well as all of the WP sub-sizes such as thumbnail, medium, large etc.

This single-file scenario should be considered for the API design in regards to WP sub-size generation for future file formats such as JPEG XL that will store multiple sizes of the same image in one file.

Exactly right - the API needs to be flexible enough to support new formats and fallbacks. The work we do landing WebP and potentially AVIF support lays a clear path for adopting additional modern formats like JPEG XL and does not exclude them.

Thank you, that's good to hear.

[adamsilverstein]

@Euene thanks for all the additional details and keeping us up to date on JPEG XL.

[mmuyskens]

Why WebP though?

I mean, it makes sense instead of JPEG but AVIF is already supported by Imagick, as well as LibGD via libavif.

WebP and MozJPEG are pretty much neck and neck in file size until you hit about 1000px wide images. WebP then becomes the loser of the two for anything larger than about that. Seems like a waste of time in my opinion to adopt WebP now.

AVIF would be the clear winner, for every size point, and is already widely supported.

[erikyo]

@mmuyskens actually not very widely supported by browsers and i guess safari support will come very late since only webp are fully supported only since the last version. IMHO webp is a good balance between support and performance