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.
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?