WordPress Performance Team Revises Proposal for WebP by Default

One year ago, WordPress 5.8 introduced support for WebP, allowing users to upload and use WebP images in their content. In March 2022, the Performance Team moved to expand core support for the image format by proposing 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 put on hold 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 warranted, as research shows more than 97% of web browsers are compatible, as are more than 97% of email clients.

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

One of the chief concerns from prior feedback 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 the JPEG sub sizes. Performance team contributor Adam Silverstein shared the team’s findings after surveying hosting companies:

To assess the overall impact of generating WebP images on site storage, the team surveyed hosting providers. With a total of 17 responses, the results show that the number of stored files is generally not an issue for most hosts/sites, although storage space could become an issue for some users over time. Still, for large hosts (with 1,000 or more hosted sites), the vast majority of sites (> 86%) would be unaffected, even if their storage requirements doubled. We also learned that some lower-end hosting plans with limited storage also lack WebP support in their hosting stack, which means they won’t get extra image generation anyway.

There may be a few assumptions baked into the statement that “the number of stored files is generally not an issue for most hosts/sites.” Responses to the team’s survey indicated that 58% of users would be unaffected by a doubling of their storage requirements. Only 17 hosts were surveyed and the names of the companies were not included in the data. Even with an estimated 14% of sites at risk of being 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 providing a JavaScript snippet that detects browsers that lack WebP support and loads JPEGs instead. Additional WebP by default revisions include the following:

  • Automatically generating WebP versions of only core image sizes in 6.1 by default. Custom image sizes will initially have to opt in to receive automatically generated WebP versions, or opt out if they are exclusively used for special cases where WebP is not beneficial or supported.
  • Keeping secondary (WebP) sub-sizes only if they are smaller than the primary MIME type.
  • Only generating WebP images for image sizes that are intended for use in user-facing front-end content. This avoids wasting storage space for WebP images that will never be used.
  • Introducing a filter to control the generation of additional MIME types based on image sub-sizes. This enables developers to exclude certain image sizes, such as those that are not used in front-end content. 

The proposal for WebP by default will only affect new images uploaded after its inclusion in core. It would not automatically generate WebP images for existing uploads. Users who want to convert past uploads would need to use WP-CLI or a plugin like Regenerate Thumbnails.

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

“One can’t simply say it’s OK because ‘the vast majority of sites (> 86%) would be unaffected,’” WordPress developer Jon Brown said. “First, 14% is terms of WordPress is a lot. We somehow need to keep supporting the 2.8% of sites still running PHP 5.6, but 14% isn’t significant?

“One needs to consider here not just IF, but HOW this 14% of sites will be affected, and not just today, but in the future as well. Will sites just have to smoothly upgrade storage, or will they run out of disk space and crash? Or backups suddenly start failing?”

Multiple participants in the comments suggested WordPress look at adopting the more modern AVIF format, which has better quality and compression when compared to WebP.

“Since this initiative is essentially a progressive enhancement, wouldn’t it make more sense to support next-gen formats like AVIF instead while gracefully falling back?” JavaScript developer Kevin Batdorf said. “Then browsers will fall into place as they add support over time.

“Moving to WebP support feels like when WordPress added the REST API while everyone was starting to shift to GraphQL. REST is great, as is WebP, but it’s current gen tech and will feel stale fast.”

Performance team contributor Bethany Chobanian Lang said AVIF is on their radar, but its browser support is still lacking at 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.


11 responses to “WordPress Performance Team Revises Proposal for WebP by Default”

  1. If a newer format is at something slightly under 30% adoption, does it not make sense to figure out how to help folks leapfrog to that one rather than investing in a transition format that does not work for some 14% of current sites?

  2. I don’t know about this, but if they don’t do something on the performance part, CMSes and web platforms like Duda, Shopify and others would soon be the preferred choice by the users who seek performance and stability over stale formats and complicated setups. I want WordPress to continue to thrive, which means they should implement new technologies fast.

    • Performance is gained by optimizing bad code, not by adding new bad code to patch old bad code. This WebP conversion will make uploading files slower, will make the database fuller, and your site load longer as it tries to test for browser support.

      The benefit is saving 5kb over a single stream, which takes less than 50 nanoseconds on modern connections, a benefit so non-profound that it cannot even be accurately measured. The processing required to make this feature a reality is a thousandfold slower, so your site will be slower thanks to this feature.

  3. “Multiple participants in the comments suggested WordPress look at adopting the more modern AVIF format, which has better quality and compression when compared to WebP.”

    AVIF quality and compression vs. WebP is marginal, while taking much longer (and more CPU cycles) to encode. Combined with lower browser adoption, I’m personally going to avoid AVIF until hardware acceleration matures (AV-1 support in CPUs).

  4. I looked at the hosting survey and what they asked is a pedestrian level understanding of account quota usage.

    Most hosts drastically oversell their storage arrays. The issue isn’t if a user is +/- the 50% point. The issue is when every account on their oversold storage nearly doubles in real storage requirements.

    That is the problem.

  5. A Google backed developer first proposes that a Google developed format is made default in WP. That first attempt was shot down.

    Somehow, that same Google backed developer is back pushing that same agenda.

    Does no-one at all see any problem with this??

    Remember, WP is / was all about the ‘open web’. Google is at the extreme opposite end of that.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: