Last week Performance team contributors were working on refining their follow-up patches for the multi-mime/WebP feature, after the main work for it was merged into core for 6.1 at the end of July. This includes smaller related items like the shim for non-supporting browsers and adding PDF support, which are being handled in separate tickets.
The proposal to generate WebP images by default for new JPEG image uploads has been controversial from the beginning. While the Google-sponsored contributors driving the project have made some revisions after an initial round of significant critical feedback, other contributors have continued to voice concerns that they said were not being considered. Several contributors reported issues with the feature and suggested that it should start by being opt-in, an idea that was summarily dismissed before the main work was committed.
Last week, WordPress lead developer Andrew Ozz weighed in on the ticket with new objections:
Like @MatthiasReinholz, @eatingrules, and others I think this approach is perhaps lacking. Why would there be twice as many image files taking up a lot of extra space when half of them will never ever be used anywhere?
IMHO a better approach would be to just make all image sub-sizes WEBP. If JPEGs are indeed needed, these can be generated on-the-fly as needed. There is no point of clogging the web servers storage with all these useless files.
On the other hand, if the WEBP file sizes are actually larger than the JPEGs, that would probably mean that better tools are needed, and this patch is premature.
Six weeks ago, in response to one complaint that the “resources for conversion would be tremendous,” Google-sponsored core committer Adam Silverstein confirmed that resources for generating the images on upload would “increase dramatically.”
“However resources to serve an image will be lowered,” Silverstein said. “Since image uploading is very rare compared to image serving, the extra effort to compress and store images should be worth it.”
This is another problem Ozz cited in his objection to this approach.
“Actually that dramatic increase of resources usage when uploading an image is a very bad side effect here,” Ozz said. “It means a lot of uploads will fail, and leave the users stranded. It also will increase support requests for both WordPress and the hosting companies dramatically. Don’t think this is acceptable. Because of this, even if image multi-mime support is needed in WordPress, the current approach doesn’t seem like a good solution.”
Approximately 24 hours later, Google-sponsored contributor Felix Arntz commented to advise that the WebP fallback mechanism to JPEG for older browsers was ready for commit and that he planned to commit it in a few days.
“Please do not commit any more code here unless it is to address the dramatic increase of resources needed to create image sub-sizes after upload,” Ozz said. “As I said above such increase is unacceptable.
“Is there any data about how much more resources (memory, processing time, etc.) are needed when uploading different image sizes? Any estimate about how many sites may be affected by that? Any suggestions on how to deal with it? Do you know what happens when post-processing of an uploaded image fails?
“Frankly for now it seems that this patch will have to be reverted and refactored in order to address this.”
Adam Silverstein responded to his concerns with clarification on why they chose the current approach, in anticipation of certain edge cases and eventually adding support for formats like AVIF once it is more widely supported:
I tend to agree with your assessment that all sub-sizes should be generated as WebP only, that was the shape of the original proposal. For the vast majority of use cases/users this will work the best. I would be open to considering this for the default (with some mitigations, see below).
The reason we decided to generate both formats was for backwards compatibility considerations for the few edge cases we identified where WebP images will might not work: namely emailed images (some older outlook/windows clients), Open Graph tags (some services don’t support WebP) and older Safari browsers. One possibility we considered would be to keep only the full sized JPEG so it is always available for those edge cases.
The “multi-mime” support here is built to generating multiple formats so you sites can provide a primary and fallback format with something like the
pictureelement. This is less important for WebP since it is so widely supported, but would be helpful for adopting newer formats like AVIF by plugins or core.
Silverstein also said the option of generating images on the fly was something they need to figure out but “felt out of scope for this effort.”
In response to the complaint regarding the dramatic increase in resources for image uploads, Silverstein said they are relying on the “retry” mechanism to mitigate this problem.
“This change also doubles the number of times WordPress will retry’ the image regeneration, so while processing time will increase, I don’t think we’ll see a jump in failures necessarily,” he said. “I know we had trouble adding new sizes in the past, however that was before we added the retry mechanism.”
The team behind the WebP by default project is more focused on serving smaller image sizes on the frontend and considers the additional resource usage on upload a necessary sacrifice for WordPress users.
“The additional resources at upload time needs to be weighed against the reduced resources of serving the smaller WebP image, especially since serving typically occurs several orders of magnitude more frequently than uploading,” Silverstein said.
“If uploading fails after all the retries, the user has the same experience as currently: they are left with a broken, unusable image. That can probably be fixed, although I don’t think this change will increases failure rates.”
WordPress lead developer Dion Hulse also commented on the ticket to report issues with WebP conversions in the WordPress Photo Directory:
Just noting here, that these additional webp conversions appear to have been the leading cause of upload failures on the WordPress Photo Directory in recent weeks. See #meta6142 and tickets closed as duplicate of it.
The errors were generally along the lines of
Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes(obviously with byte values) while attempting to perform the initial full-size-original jpeg -> webp conversion.It hasn’t affected every upload, only that of certain images. Potentially related to the
$qualityvalue being passed for webp requests (IIRC the default of 82 was optimized for jpeg?).
Hulse disabled the JPEG to WebP conversion as a result of these errors, as the photo directory doesn’t currently use WebP but noted that it “might be a sign that it might be worth considering only generating webp’s for the resized images, rather than for the original file too.”
Silverstein said they are investigating the issues Hulse reported, as it may have exposed a bug.
Ozz circled back to recommend that making sub-sizes on demand would be a better approach that has faster processing of uploaded images and reduced space requirements, since the additional JPEG images would not be generated unless needed. He also noted that the “retry” for image post-processing “doesn’t work as well as expected.”
“The bad news is that if the post processing fails, chances are the originally uploaded file will remain,” Ozz said. “Then it will be used everywhere as most of the code in WP falls back to available sizes, and the only size will be the original. That means we will be serving huge (4MB – 8MB average) images. A serious drawback.”
Silverstein responded to Ozz’s suggestions, agreeing with many, and proposed two potential paths forward for the project:
- Keep the current multi-mime infrastructure, but change the defaults so only WebP files are generated, possibly up to a threshold size beyond which only JPEGs would be generated. Most existing work would continue; content filtering could possibly be removed.
- Revert the multi-mime infrastructure and switch back to a single mime approach, using WebP for images up to a threshold size and adjusting the compatibility layer to use the JPEGs we keep.
The Performance team is doing more research and has temporarily paused committing anything else until they receive feedback on the next direction for the project.
I would love to see ALL image sizes get generated on the fly as needed. Pre-generating all the images creates so many extra files that never get used.