WebP by Default Once Again on Hold by WordPress Lead Developers

The WebP by default functionality has been put on hold again due to certain objections from WordPress key developers.

After the major work for the multi-mime/WebP functionality was pushed into core for 6.1 at the end of July, performance team developers spent last week honing their follow-up changes. This covers small related topics such as the shim for non-supporting browsers and adding PDF support.

The idea to produce WebP pictures by default for new JPEG image submissions has been divisive from its conception. WebP by default allows websites to better compress their pictures in order to conserve bandwidth, which substantially increases speed. Due to the disadvantages of WebP, such as the higher storage and computational power needed when uploading photos, development was halted for further investigation.

The feature was included in a future WordPress edition in the middle of April of this year. However, the original plan was revised, and it was integrated into the WordPress 6.1 release. Yet, WordPress head developer Andrew Ozz came forward with some objections on a ticket.

“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 in clogging the web server’s 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.”

Adam Silverstein, a Google-sponsored WordPress core committer, has commented that the resources necessary for producing mime images while uploading a picture will significantly increase, while the resources required for providing such images will decrease.

“However, resources to serve an image will be lowered. Since image uploading is very rare compared to image serving, the extra effort to compress and store images should be worth it.”

Ozz finds an issue there because he believes picture uploads will begin to fail on constrained servers, which he considers unacceptable.

“Actually that dramatic increase of resource usage when uploading an image is a very bad side effect here. 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.”

Google-sponsored contributor Felix Arntz responded to the situation that the WebP JPEG backup method for older browsers was prepared for commit and that he planned to commit it in the next few days.

Silverstein also stated that they need to work out how to generate pictures on the fly, but it seems out of scope for this work. And in response to a concern about the large increase in resources for picture submissions, Silverstein stated that the “retry” technique is being used to address the problem.

Ozz returned to indicate that generating sub-sizes on demand would be a superior technology with faster processing of uploaded photos and lower space needs because new JPEG images will be created only when needed. He also stated that the picture post-processing “retry” function “doesn’t operate as well as intended.”

After several debates, the WordPress Performance team has decided to suspend committing to WebP by default and will do more investigation into those concerns.