WordPress 6.1 ‘s plan to adopt WebP images by default has been suspended again

Last week, contributors to the performance team were working to improve follow-up patches for their multi-mime/WebP feature, after major work on the feature was merged into the core of 6.1 at the end of July. This includes smaller related items, such as shim for unsupported browsers and adding PDF support, which are handled in separate jobs.

The proposal to generate WebP images by default for new JPEG image uploads has been controversial from the beginning. While Google-sponsored contributors to push the project made some changes after the first round of important critical feedback, other contributors continued to express concerns they said they were not being considered. Some contributors reported problems with the feature and suggested that it should start with an opt-in, an idea that was dismissed immediately before the main work was submitted.

WordPress 6.1 's plan to adopt WebP images by default has been suspended again

Last week, WordPress chief developer Andrew Ozz raised new objections:

Like @MatthiasReinholz,@eatingrules and others, I think this approach may be lacking. Why are twice as many image files taking up a lot of extra space when half of them will never be used anywhere?

With all due respect, a better approach is to set all image size to WEBP. If you do need JPEG, you can generate it immediately as needed. There is no need to block storage on the Web server with all these useless files.

On the other hand, if the WEBP file size is actually larger than JPEG, that could mean a better tool is needed, and this patch is premature.

Six weeks ago, Google-sponsored core submitter Adam Silverstein confirmed in response to a complaint that “conversion resources will be huge” that the resources used to generate uploaded images will “increase dramatically.”

“But resources will be reduced to serve images,” Silverstein said. “Since image uploads are very rare compared to image services, the extra effort to compress and store images should be worth it.”

This is another issue Ozz cited when opposing this approach.

“In fact, the sharp increase in resource usage when uploading pictures is a very bad side effect here,” Ozz said. “This means that many uploads will fail, leaving users in trouble. It will also significantly increase support requests for WordPress and hosting companies. Don’t think this is acceptable. Because of this, even if WordPress requires image multi-mime support, the current approach doesn’t seem to be a good solution.”

About 24 hours later, Google-sponsored contributor Felix Arntz commented that the old browser’s WebP fallback mechanism to JPEG was ready for submission, and he planned to submit in a few days.

“Please don’t submit more code here unless it’s to address the dramatic increase in resources required to create image size after upload,” Ozz said. “As I said above, this increase is unacceptable.

“When uploading images of different size, is there data on how much resources (memory, processing time, etc.) are needed? Estimate how many websites may be affected? Any suggestions on how to deal with it? Do you know what happens when processing fails after uploading an image?

“Frankly, at this point, it seems that this patch must be restored and refactored to solve the problem.”

Adam Silverstein responded to his concerns, clarifying why they chose the current approach, anticipating certain extreme scenarios, and ultimately increasing support for formats such as AVIF once it gained wider support:

I tend to agree with your assessment that all sub-size should be generated only as WebP, which is the form of the original proposal. For the vast majority of use cases/users, this will be the best. I would like to consider this as the default setting (there are some mitigations, see below).

The reason we decided to generate these two formats was because of backward compatibility considerations, and we identified a few marginal situations where WebP images might not work: namely email images (some older Outlook/Windows clients), Open Graph tags (some services don’t support WebP), and older Safari browsers. One possibility we considered was to keep only the full size JPEG so that it could always be used for those edge situations.

The “multi-mime” support here is designed to generate multiple formats, so your site can provide a package with picture The primary and alternative formats such as elements. This is less important for WebP because it is widely supported, but is helpful for adopting new formats such as AVIF through plug-ins or cores.

Silverstein also said the options for dynamically generating images were something they needed to figure out, but “felt beyond the scope of this work.”

In response to complaints about the sharp increase in image upload resources, Silverstein said they are relying on a “retry” mechanism to alleviate the problem.

“This change also doubles the number of times WordPress retries image renditions, so while processing times will increase, I don’t think we will necessarily see a surge in failures,” he said. “I know we had trouble adding new size in the past, but that was before we added the retry mechanism.”

By default, the team behind the WebP project is more focused on providing smaller image size on the front end and believes that the extra resource use during upload is a necessary sacrifice for WordPress users.

“The extra resources at upload need to be weighed against the reduction in resources for serving smaller WebP images, especially since services typically occur orders of magnitude more frequently than uploads,” Silverstein said.

“If the upload fails after all retries, users will get the same experience as they currently have: the images they leave behind are corrupted and unusable. This may be solvable, although I don’t think this change will increase the failure rate.”

WordPress chief developer Dion Hulse also commented on the ticket to report WebP conversion issues in the WordPress Photo Catalog:

Please note that these additional webp conversions appear to be the main reason for WordPress photo catalog uploads in recent weeks. Please refer to #meta6142 and the ticket is closed as a copy of it.

Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes When trying to perform the initial full size raw jpeg-webp conversion, the error is usually related to (obviously to byte values).

it didn’t affect each uploadIt only affects certain images. possible with $quality Depending on the value passed for webp requests (is the IIRC default value of 82 optimized for jpeg?).

Because of these errors, Hulse disabled JPEG to WebP conversion because photo catalogs don’t currently use WebP, but noted that this “may indicate that it may be worth considering generating webp only for resized images, rather than for the original file.”

Silverstein said they are investigating the issue reported by Hulse because it may have exposed an error.

Ozz instead suggested that making size on demand would be a better approach, which would process uploaded images faster and reduce space requirements because no additional JPEG images would be generated unless needed. He also pointed out that “retries” of image post-processing “did not work as expected.”

“The bad news is that if post-processing fails, the files originally uploaded will likely remain,” Ozz said. “Then it will be used anywhere because most of the code in WP falls back to the available size, and the only size will be the original size. This means we will provide huge (average 4MB 8MB) images. A serious shortcoming.”

Silverstein responded to Ozz’s suggestion, agreed with many, and suggested two potential paths forward for the project:

  1. Keep the current multi-mime infrastructure, but change the defaults to generate only WebP files, possibly reaching a threshold size beyond which only JPEG will be generated. Most existing work will continue; content filtering may be removed.
  2. Restore the multi-mime infrastructure and switch back to the single mime method, use WebP for images that reach the threshold size, and adjust the compatibility layers to use the JPEG we reserved.

The performance team is doing more research and temporarily stopping submitting anything else until they receive feedback on the next direction of the project.

Note: The text content comes from WordPress Tavern and is translated and compiled by WordPress University.

Regarding the topic of “WordPress adopts WebP by default”, if you have any thoughts, please comment and share them below.

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注