WordPress Performance Team Revises Proposal for Default WebP – WP Tavern

A year ago, WordPress 5.8 introduced WebP support, allowing users to upload and use WebP images in their content. In March 2022, the Performance team decided to extend basic image format support by proposing that WordPress enable WebP by default. This would include generating WebP images for new JPEG uploads and using WebP images for website content. In April, the controversial proposal was shelved after significant critical feedback.

After months of research, the team has reassessed its approach and summarized its findings. The concern about WebP compatibility doesn’t seem justified, because to research shows that over 97% of web browsers are compatible, as are over 97% of email clients.

Mobile apps have strong compatibility with iOS 14+ supporting WebP (older versions will be served in JPEG) and Android supporting WebP natively from Android 4.0. The team discovered that all of the top RSS readers support WebP. The only compatibility outlier is with Open Graph consumers, which have mixed support.

One of the main concerns from previous comments was that the proposal has the potential to double the amount of disk space used for images, as it would generate WebP thumbnails in addition to JPEG subsizes. Performance team contributor Adam Silverstein shared the team’s findings after surveying hosting companies:

To evaluate the whole impact of WebP image generation on site storage, the team interviewed the hosts. With a total of 17 responses, the results show that the number of files stored is generally not an issue for most hosts/sites, although storage space may become an issue for some users over time. Yet, for large hosts (with 1,000 or more hosted sites), the vast majority of sites (>86%) would not be affected, even if their storage needs doubled. We also learned that some low-end hosting plans with limited storage also don’t support WebP in their hosting stack, which means they won’t get an image build anyway. additional.

There may be some assumptions built into the statement that “the number of files stored is generally not an issue for most hosts/sites”. The team’s survey responses indicated that 58% of users would not be affected by a doubling of their storage needs. Only 17 hosts were interviewed and company names were not included in the data. Even with around 14% of sites likely to be near capacity, this has the potential to impact millions of WordPress sites.

The Performance team is proposing a few notable changes to address concerns, including provide a JavaScript code snippet which detects browsers that do not support WebP and loads JPEG files instead. Default additional WebP revisions include the following:

  • Automatic generation of WebP versions of only base image sizes in 6.1 by default. Custom image sizes will initially need to opt-in to receive auto-generated WebP builds, or opt-out if exclusively used for special cases where WebP is not beneficial or supported.
  • Preserve secondary subsizes (WebP) only if they are smaller than the main MIME type.
  • Only generate WebP images for image sizes intended for use in user-facing front-end content. This avoids wasting storage space on WebP images that will never be used.
  • Introduced a filter to control the generation of additional MIME types based on image subsizes. This allows developers to exclude certain image sizes, such as those not used in front-end content.

The default WebP proposal will only affect new images uploaded after it is included in the core. It would not automatically generate WebP images for existing uploads. Users who want to convert past downloads should use WP-CLI or a plugin like Regenerate Thumbnails.

Revisions to the proposal have so far received mixed reviews. Some are strongly in favor of the new approach and others encouraged the team to consider some of the practical implications for users who might be impacted.

“You can’t just say it’s OK because ‘the vast majority of sites (>86%) wouldn’t be affected,'” WordPress developer Jon Brown said. “First, 14% of WordPress terms is a lot. We need to somehow continue to support the 2.8% of sites that are still running PHP 5.6, but 14% isn’t that significant?

“One must consider here not just IF, but HOW these 14% of sites will be affected, and not just today, but also in the future. Will sites just have to gracefully upgrade storage, or will they miss- they run out of disk space and crash? Or do backups suddenly start to fail?”

Several comment participants suggested that WordPress consider adopting the more modern AVIF format, which offers better quality and compression compared to WebP.

“Since this initiative is essentially an incremental improvement, wouldn’t it make more sense to support next-gen formats like AVIF instead while falling back gracefully?” JavaScript developer Kevin Batdorf said. “Then browsers will roll out as they add support over time.

“Moving to WebP support is like when WordPress added the REST API when everyone was starting to move to GraphQL. REST is great, and so is WebP, but it’s current gen technology and it will quickly feel outdated.

Performance Team Contributor Bethany Chobanian Lang said AVIF is on their radarbut its browser support is still lacking on less than 70% of the web.

The conversation continues in the comments of the update and Silverstein also encouraged participation on the Trac ticket for the revised approach. Performance team contributors aim to merge this change early in the 6.1 release cycle to get more testing.

Comments are closed.