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

• [x] #4
• [x] #142
• [x] #149

Required for following plugin release and initial core patch

• [x] #167
• [x] #174
• [x] #187
• [x] #204

Required for initial core patch merge

• [x] #228
• [x] #237
• [x] #238
• [x] #186
• [x] #160
• [x] #295
• [x] #333

Exploration

• [x] #69
• [x] #70
• [x] #74
• [x] #96
• [x] #150

Misc. bugs

• [x] #67
• [x] #75
• [x] #122
• [x] #146

Research

• [x] #289
• [x] #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: https://github.com/WordPress/performance/issues/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

[adamsilverstein]

@mmuyskens thanks for the question/feedback

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.

But is MozJPEG usable by WordPress via libGD or Imagick? or part of PHP (which now bundles GD)?

I'm hoping we see more like a %30 improvement on average, higher for mobile sites, currently the httparchive data reflects that for WordPress pages that use WebP over jpeg [query].

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

We do plan to move forward with investigating AVIF next. Given the lower browser support, that also implies picture element support and better internal handling of multiple mime sub-types in core. WebP is more widely supported and for most users could be a substitute for jpeg sub sizes.

[felixarntz]

I've adjusted this issue to "officially" be a [Type] Overview issue for the overall "WebP Uploads" module, since the issue is somewhat phrased for that project and has "inofficially" been acting as such for a while. I've changed the issue description to provide an overview of the currently relevant issues for the project, so it would be great to maintain it in the future, at least with the most important issues to follow along.

Last but not least, I went over all those issues to add the [Module] WebP Uploads label. I think for overview purposes it would be great if we could add that to any new issues that tie into the "WebP for new uploads" project, since the [Focus] Images label encompasses quite a bit more.

cc @adamsilverstein

[felixarntz]

@adamsilverstein @mitogh @eclarke1 Now that we have a clear goal on #174, I've moved that to the key enhancements, and I've broken them apart with one more section for the next plugin release. I think #174 and #187 are the top priorities once #149 is completed (PRs for all of them can already be started at this point though), since they substantially affect the overall implementation.

158 is also important, but it's a bit of a more niche use-case support, which is definitely critical for the core implementation, but the plugin could be okay without it.

[felixarntz]

I've updated the issue description to reflect the latest developments, particularly I broke down the remaining issues a bit more between what is a P0 for the initial core patch and what could also go into separate follow-up core patches.

[erikyo]

I suggest to take a look at this article i found today about the difference between mozjpeg and jpeg-turbo... It seems that in the end it is not worth of it, considering the longer encoding time and the minimal difference in term of filesize.

What About mozjpeg?

TLDR;

• Mozjpeg relies on three technologies (progressive JPEG encoding, jpgcrush, and trellis quantization) to reduce the size of JPEG images. Progressive JPEG is supported in libjpeg-turbo, but jpgcrush and trellis quantization are not.

• When compared to progressive JPEG alone, the addition of jpgcrush and trellis quantization improved the compression ratio by 4-15% (average 8.3%) in our testing but increased encoding time by approximately 4-7x. Decoding time was, however, reduced by anywhere from 2-62%.

• When compared to baseline (the only mode that is fully accelerated in libjpeg-turbo), the combination of progressive JPEG, jpgcrush, and trellis quantization improved the compression ratio by 15-27% (average 20%) in our testing but increased encoding time by approximately 34-59x. More than half of the compression ratio improvement came from the use of progressive JPEG, which is supported in libjpeg-turbo as well. Decoding time was increased by anywhere from 17% to 3x, with most of this again being due to the use of progressive JPEG.

[BlogAid]

Thanks, Erik!! Agreed that MozJPEG is not the highest performer, but it is something easy for my clients to do and wins out in speed tests compared to other methods and avoids needing fallback images. I'm excited about the new formats that are coming out and hope adoption for them is fast so we can start using them as our standard.

[erikyo]

Ciao @BlogAid, the issue with MOZjpeg is that currently cannot be used with ImageMagick (and therefore also with WordPress), so at the moment isn't considered a viable way unless you want to convert all images manually or with a plugin.

I wrote a post on how to install it on ubuntu but since it's a fork of turbojpeg the command has the same name (cjpeg // djpeg) and it should replace the default one in order to be enabled (in addition requires some configuration via shell), it's a complex configuration and not recommended.

I've prepared a website to compare the new and the old image formats, for the moment there is a copy of the WordPress home called "original" and for each format a page where all the images are encoded in that format. I plan to add in the near future some pages to compare also the weight at different qualities.

[eclarke1]

Updated the epic description to remove #155 and #158

[BlogAid]

@erikyo Thank you so much for the MOZjpeg testing and extra info about what it would take to include in WP.

I have a couple of comments and questions.

Anyone who cares about speed has already made arrangements for their images, either with manually optimizing prior to upload or using an image optimization plugin.

My clients were mostly using ShortPixel or similar and were stunned to see just how many images were on their disk space due to the fallback images. They have image-heavy sites and realized they would have to increase their hosting at some point, not to mention the cost of backups.

They elected to have the plugin removed in a way that retained only the optimized set of images (I did that for them, as it is not always user friendly with some of the plugins for them to do it.)

And they began doing manual optimization via Squoosh, then uploading.

The main image we are concerned about is the first full-size image on a post (most all of my clients are bloggers). Because it is the original, not a thumbnail, they get the progressive render and it is seen by Chrome as a modern format. The rest of the images on the page do not count toward initial load speed as lazy load is applied to them.

My 2 concerns with this project is that it proposed to use WebP, which doubles the image load, and that it does the conversion on the site, which is basically what all other image optimization plugins do now. If folks want to do either of those things, that's their choice, and should remain so.

My question is, from the testing you have done with the processing and such for MozJpeg, what if folks are already doing the optimization manually, and then uploading it? Is there a way to have WP carry that file format through to the thumbnails so that they also render as Progressive?

I just want to be clear that your testing is not just for the intial conversion on upload, but that it includes just supporting the format already uploaded all the way through the thumbnails.

If it can't, that's okay. We are still getting a smaller file size to begin with, and load time is still faster as is on all pages, including the home page, which is all thumbnails.

[erikyo]

My clients were mostly using ShortPixel or similar and were stunned to see just how many images were on their disk space due to the fallback images.

What I get is that some users have no control over the number of thumbnails, but I would rather ask a better management of the thumbnail than restricting myself to not use webps. Imho if you have harddisk space costs the decisive factor is the number of large resizes, usually it's enough to remove a couple of (unused) oversize images. Look at this array that a guy has posted a few days ago on slack:

the array of image meta (clic to show)

``` Array ( [width] => 2500 [height] => 1665 [file] => 202X/XX/image.jpg [sizes] => Array ( [medium] => Array ( [file] => image-300x200.jpg [width] => 300 [height] => 200 [mime-type] => image/jpeg [sources] => Array ( [image/jpeg] => Array ( [file] => image-300x200.jpg [filesize] => 11736 ) -> 11KB [image/webp] => Array ( [file] => image-300x200.webp [filesize] => 10034 ) ) ) -> 10KB [large] => Array ( [file] => image-1024x682.jpg [width] => 1024 [height] => 682 [mime-type] => image/jpeg [sources] => Array ( [image/jpeg] => Array ( [file] => image-1024x682.jpg [filesize] => 81920 ) -> 81KB [image/webp] => Array ( [file] => image-1024x682.webp [filesize] => 57348 ) ) ) -> 57KB [thumbnail] => Array ( [file] => image-150x150.jpg [width] => 150 [height] => 150 [mime-type] => image/jpeg [sources] => Array ( [image/jpeg] => Array ( [file] => image-150x150.jpg [filesize] => 5479 ) -> 5KB [image/webp] => Array ( [file] => image-150x150.webp [filesize] => 4854 ) ) ) -> 4KB [medium_large] => Array ( [file] => image-768x511.jpg [width] => 768 [height] => 511 [mime-type] => image/jpeg [sources] => Array ( [image/jpeg] => Array ( [file] => image-768x511.jpg [filesize] => 52140 ) -> 52KB [image/webp] => Array ( [file] => image-768x511.webp [filesize] => 38590 ) ) ) -> 38KB [1536x1536] => Array ( [file] => image-1536x1023.jpg [width] => 1536 [height] => 1023 [mime-type] => image/jpeg [sources] => Array ( [image/jpeg] => Array ( [file] => image-1536x1023.jpg [filesize] => 151942 ) -> 151KB [image/webp] => Array ( [file] => image-1536x1023.webp [filesize] => 98596 ) ) ) -> 98KB [2048x2048] => Array ( [file] => image-2048x1364.jpg [width] => 2048 [height] => 1364 [mime-type] => image/jpeg [sources] => Array ( [image/jpeg] => Array ( [file] => image-2048x1364.jpg [filesize] => 237001 ) -> 237KB [image/webp] => Array ( [file] => image-2048x1364.webp [filesize] => 146106 ) ) ) -> 146KB ) [sources] => Array ( [image/jpeg] => Array ( [file] => image.jpg [filesize] => 338323 ) -> 338KB [image/webp] => Array ( [file] => image.webp [filesize] => 211226 ) ) -> 221KB ) ```

Just remove the formats "1536x1536" and "2048x2048" to halve the space used. This is the default array, I've heard of people with more than 50 resizes. I'm pretty sure that they don't use them all and it would be enough a small rationalization to fix the problem (and probably even speed up the page load since the browser will use those images already in cache)

What if folks are already doing the optimization manually, and then uploading it?

Only the first image is copied and the other thumbnails are generated with turbo-jpeg, so only the full image is a MOZjpeg while all the others are jpeg baseline.

I just want to be clear that your testing is not just for the intial conversion on upload, but that it includes just supporting the format already uploaded all the way through the thumbnails.

yep I was trying and there is a way to get MOZjpeg with imagemagick but needs some hacks to get it working, an ssh access to the linux shell etc. I think the goal of the performance group is to popularize this without doing difficult stuff. As far as it concerns to get all the jpegs with the progressive compression I think @adamsilverstein is already looking at it and honestly it is a good idea. The substantial difference between jpg and mozjpeg you are referring to is between baseline jpg and MOZjpeg, while progressive jpg are in the beetween and only slighly less compressed than mozjpg.

[zero4281]

@BlogAid

My clients were mostly using ShortPixel or similar and were stunned to see just how many images were on their disk space due to the fallback images. They have image-heavy sites and realized they would have to increase their hosting at some point, not to mention the cost of backups.

If you're only interested in what's best for your clients and they already have ShortPixel then why is this an issue for you? They can keep using whatever image optimization service that they want and the default behavior is configurable. I don't understand why this is an issue for you or why you didn't understand that MOZjpeg wasn't an option in GD or ImageMagick. This has been explained over and over.

I'm not saying that I disagree with all of your points, I just think that you're missing any point except what hits your own pocketbook. I could say the same thing for every other type of service provider. It's very likely that the majority of service providers will see a reduction in bandwidth, but all of the naysayers are focused on the cost of disk space. This seems like a net gain to me, not a net loss. If you want to argue with me then I'd like to see some hard financial numbers instead of complaints that are clearly based on a misunderstanding of the goals including the total net cost

@adamsilverstein All of that aside, I would still like to see this hold off until WordPress 6.1 so it has ample time for testing. I suspect that the ability to configure could use significantly more work in both the GUI and the lack of support in wp-config.php. If service providers are able to limit this functionality out of the box with a configuration instead of a WordPress hook, then this might be much easier for them to swallow.

WordPress is about decisions, not choices......but my decision is about choices. Maybe the powers that be shouldn't be so opinionated about how we all handle things, and the arguments should be about the overarching philosophy and not the specific implementation.

[BlogAid]

We remove any optimization plugin they are using, plus the duplicate images, and go with the manual optimize before upload method. ALL of that info was in my original post - did you not read it?

I NEVER pushed for MozJPEG to be used for this feature - I used it as a test bases against what this feature - and what ALL of the image optimization plugins do.

And then I ASKED if there was a way to have MozJPEG be carried through the thumbnails.

By service providers, do you mean hosts? So many site owners are on shared hosting a most of them give unlimited bandwidth now - but they do limit inodes due to limits on their own server backups.

There are 445 million sites running WP - we need case studies on multiple setup conditions to get that hard data and ensure that no harm is being done with new features like this being presented.

And look again at how many dissents there were about this in both the Performance Team channel and on the proposal about why WebP is not everyone's darling and why this should remain in the plugin territory.

We have wasted more time going in circles with these same arguments for 6 months than we have spent on ALL other Performance Team projects combined. @erikyo was bringing new tests to the table - and I'm happy to spend time on that. But I won't give another ounce of my life to having the same discussion over and over.

[adamsilverstein]

I opened up this follow up ticket to investigate MozJPEG further - https://github.com/WordPress/performance/issues/294 to research questions like how available it might be in WordPress hosting environments , what it would take to determine that, and if that might be improved (eg could it be available by default in PHP?).

[adamsilverstein]

It's very likely that the majority of service providers will see a reduction in bandwidth, but all of the naysayers are focused on the cost of disk space

Good insight @zero4281 - the disk space/#of files issue primarily effects website owners/builders, while the performance gains primarily benefit website visitors (both effect hosts as well).

[mukeshpanchal27]

Resolved by the Modern Image Formats plugin