Performance Team Proposes Enabling WebP by Default in WordPress 6.0

WordPress’ Performance Team has published a feature proposal that would enable WebP images by default, expanding core support for the modern image format.

In July, 2021, WordPress 5.8 introduced WebP support, allowing users to upload and use WebP images in their content. If the proposal is approved, version 6.0 will generate WebP images by default for new JPEG uploads and will use WebP images by default for website content.

“WebP was developed as a modern image format that provides superior compression on the web,” WordPress core contributor Adam Silverstein said in the feature proposal. “Images are often some of the largest resources used by websites, and using WebP creates websites that are lighter and faster. Compared to JPEG images, WebP images generated by WordPress are almost always smaller, with a ~30% file size reduction on average (with the same visual quality).”  

With WebP enabled by default, WordPress users would not experience any changes to their usual image upload workflow. WordPress would automatically convert JPEG uploads to WebP in the background and use them on the website.

According to Can I Use, the WebP image format is supported by 94.25% of web browsers. A very small number of browsers, such as Internet Explorer 11 or Safari on MacOS < v11 Big Sur, do not support WebP.

The proposed feature would ship with two filters to control or disable WebP uploads, and a user-friendly plugin would be created to do the same.

Despite the significant performance benefits, support for the feature proposal is not unopposed. Several contributors participating in the discussion expressed concerns about email clients and social media platforms not supporting WebP.

“I feel like WebP is not yet ready to become a ‘hardcoded default’ in the post_content due to all the reasons mentioned in the previous comments,” Kaspars Dambis said. “Many web clients (which are not just browsers) don’t support WebP formats — RSS clients, email clients, smart TVs, ebook readers, open graph parsers, desktop image viewers, etc. These are all important users of the web.”

Silverstein answered these concerns, confirming that WordPress will continue generating the JPEG image sub sizes as it always has.

“One important note about what this feature doesn’t change: JPEG sub sizes are still generated and stored in the same meta fields,” he said. “For that reason, consumers of RSS feeds or REST media endpoints or OG tags for example will continue to use the JPEG sub sized versions.”

The Performance Team contributors are targeting WordPress 6.0 for enabling WebP by default and are seeking approval from maintainers of the image component. Anyone is welcome to test the feature by installing the Performance Lab plugin with the “WebP Uploads” module activated. Testers are encouraged to leave feedback on the Trac ticket or Pull Request.

11

11 responses to “Performance Team Proposes Enabling WebP by Default in WordPress 6.0”

  1. For the past few weeks I’ve been trying out webp images.

    99% of the times when I convert PNG images to WEBP , the WEBP is smaller.

    However, JPG —> WEBP , the WEBP is NOT smaller.

    I used GIMP whatever is the latest version.

    It’s bad enough that when I upload an image, there are different sizes in the uploads directory. Now when I upload a JPG or PNG…it will make a copy in WEBP? So two of every image at least?

    I do not like that, will it do different image sizes as well for the WEBP?

    I use JPG = photos, PNG = graphics (non-photos).

    I converted all PNGs to WEBPs.

    One of my sites has 300-ish flags of every country and sort of not really recognized regions. It’s for a weather section.

    So each page has the flag of the country beside the flag of the city plus the map (with a pin pointing to the location of the map in the country).

    I don’t want WordPress to do multiple image sizes or/and multiple image formats.

    Let ME upload a jpg, webp, png or even gif.

    Do people still use gif?

    I also have a photography site, I think I have over 3.5 million photos. This is what happens when you have a photography site since 2005.

    If this goes through, am I going to have 7 million images now?

    • It seems like that at first glance, but this is going to dramatically increase the disk space needed by sites. On a small site, it may not matter much. But on sites with large media libraries, it’s going to be extremely problematic. In addition to needing more disk space, it will also make backups, restores, and migrations more challenging.

      The developers have said that they’re asking for people to test things out to make sure it works, but these kinds of problems are going to surface after months or years — and they seem to be completely ignoring the ramifications of this.

  2. It would be great if WordPress has the ability to convert to WebP without a plugin. However, I think it should be a one-click option within core. You shouldn’t need a filter or a separate plugin to turn it off.

    Maybe a bit of onboarding is what’s needed here. When a user uploads an image for the first time, perhaps something mentions the benefits of WebP. From there, they have the chance to enable the feature.

  3. Being that Webp is a Google thing I don’t trust it at all. Along with almost all browsers being based on Chrome the web is quickly becoming Google’s back yard. We won’t see the error of this path until it is too late. I think building this into Core and defaulting it is a mistake. I have and always will be in favor of user choice, be it this or auto-updates. Its very frustrating that as genuine alternatives begin disappearing those left are beginning to force new, more restrictive standards on us.

  4. This is a step in the right direction. We all know image size is one of the main points for optimization, and PageSpeed Insights always complains about pictures not having the “modern” WebP. It would be great to have this conversion by default!

  5. This is a poorly considered proposal and should not go in core. The developers of this project clearly do not have a good understanding of how most site owners actually use WordPress.

    Media libraries are already overly bloated because of the massive numbers of thumbnails that are generated automatically (it’s not at all uncommon for sites to generate 30 to 50 thumbnails for every image!). Most of those thumbnails go unused and take up expensive disk space. And this proposal will nearly double that usage.

    This is going to effectively take every media library on every site and multiply its disk usage by ~1.7. (The changes will currently only apply to newly upload images; however, when you regenerate thumbnails it will apply to all of those.)

    This is a clunky way to implement WebP — just doubling image files, most of which won’t ever even be used. And, what happens when AVIF (which is potentially a better format) gains widespread adoption? Do we create additional thumbnails for that too?

    There are also significant conflicts of interest. WebP is a format that Google Created — and it’s Google Engineers who are leading the Performance Team. This proposal is designed to serve Google’s interests (making it easier and cheaper for them to crawl the web). And the increased cost for all the additional storage space needed will be borne by site owners, not by Google.

    They say they have consulting the hosting community — but commodity hosts like Bluehost, Siteground, and Dreamhost (the “official” recommendations here https://wordpress.org/hosting/ ) will just tell people to buy more storage space — increasing their profits.

    I encourage everyone to read the comments on the proposal and chime in there.https://make.wordpress.org/core/2022/03/28/enabling-webp-by-default/

    This SEJ article also pulls out some of the key issues reflected in the comments:https://www.searchenginejournal.com/wordpress-proposal-backlash/

    • It’s astounding to see how easy is for Google to easily sneak into the WordPress project with proposals that are only designed to serve the company’s interests. First it was AMP, and now this. It’s sad that substantially more useful proposals take years to be committed into core needing a featured plugin in order to do so and this feature can make it into core with no problems just a couple of weeks before entering the 6.0 beta phase.

Newsletter

Subscribe Via Email

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