WebP by Default Merged Into Core for WordPress 6.1

WebP, an image format developed by Google, which is intended to replace JPEG, PNG, and GIF file formats, will soon be generated by default for new JPEG image uploads in WordPress and used for website content. The main work for this feature was committed to core for inclusion in the upcoming WordPress 6.1 release.

The initial proposal was revised after significant critical feedback. The most notable changes include automatically generating WebP versions of only core image sizes, keeping secondary (WebP) sub-sizes only if they are smaller than the primary MIME type, and only generating WebP images for image sizes that are intended for use in user-facing front-end content.

Despite a raft of revisions, and filters to control or disable WebP uploads, the proposal remained controversial. Contributors continue to report issues after testing. Many still have reservations about whether this should be opt-in or on by default.

“When converting medium-resolution photographs (approx 1600px – 2500px on the long edge), WebP files are often larger than the JPEG equivalent,” WordPress developer Mark Howells-Mead commented on the main ticket for WebP work. “(In my tests using my own photography, in around 60% of cases.) This change might make the ‘modern image format’ test of Page Speed Insights happy, but enforcing WebP by default on sites which use a lot of photography will often cause longer image loading times.”

Some developers are supportive of the change but prefer for it to be off by default when it is first rolled out, to allow the ecosystem to prepare for the change.

“I definitely see it as a big advantage to add Core support for additional MIME types for sub-sized image files,” Matthias Reinholz said. “But I can’t see adding conversion to a specific other file format as preferred behavior. This may help to optimize the market position of WebP but it will also be a serious threat to plugin authors and existing larger websites that do not pay attention to this change.

“Therefore, I’m questioning why this functionality should be activated by default at this stage. IMHO, it should be opt-in only. Plus ideally, we would already start to think about adding further image formats to be supported by this feature.”

NerdPress founder Andrew Wilder created a separate ticket urging contributors to consider making the feature opt-in, but the ticket was closed and conversation directed back to the main ticket so as not to splinter the discussion.

“Making these new features opt-in instead of opt-out would be the best way to be cautious about potential impacts,” Wilder said.

“There have been many requests for this to be opt-in (as well as some asking for a setting on the Media page, rather than only a filter for developers). So far there hasn’t been any open conversation about why that’s not being taken into consideration.”

The notion that WebP by default should be opt-in was summarily dismissed and the conversation was not revisited before the changes were committed.

“The feature will have widespread benefits for users by opting in core sizes (to start) – if it were entirely opt-in it would have little impact – or benefit,” Google-sponsored Core Committer Adam Silverstein said in response to opponents.

In response to suggestions that this feature ship with a UI for enabling it on the media page, Silverstein said, “We have discussed both suggestions in chats and issues with mixed responses. Project philosophy is regularly mentioned as aligning with the current approach.”

The ticket remains open awaiting patches for a few loose threads on the technical implementation. Contributors have continued to chime in with additional concerns.

The Performance team has a new blog where people can follow updates on their current projects and proposals. Now that the main WebP work has been committed, the next steps will discussed in future meetings with notes posted to the new Core Performance blog.

23

23 responses to “WebP by Default Merged Into Core for WordPress 6.1”

  1. For my use, I don’t much care if it is opt-in (preferred) or opt-out, as long as it is not mandatory, so I can choose what works best for my 4 sites on different hosts.
    I just converted an image from WebP for a friend with an older computer, and the JPEG was MUCH smaller. I would like to be able to choose for each photo, as I find that some photos are smaller in PNG vs JPEG, others JPEG is smaller.

  2. I appreciate the work that went into this, and I think WebP conversion is a great feature to have. Still, I can’t understand why it wouldn’t be presented as a simple option in Settings > Media.

    Even if that setting were turned on by default, having a quick way to disable it would be a logical thing to do.

  3. I tried converting jpg, gif and png files….both gif and png converted into webp are much smaller.

    JPG however is not. I will continue to use JPG until webp is smaller.

    I see all these people saying how JPG–>WEBP is smaller, but over 5,000 tests……..not for me.

    I use GIMP (whatever the latest version is).

    For someone who uses a lot of photographs……..even 3kb will make a difference. Any of you photographers out there will understand what I am saying, right?

  4. I’ve tested webp a number of time in the last three years and found it problematic. After a number of days images stopped appearing at all. I know that in some instances this was Cloudflare related. Whatever the reason, forcing something like this is never a good reason. Seems like WordPress these days is fairly autocratic.

  5. Cloudflare polish does this on the fly. It considers whether the original is actually smaller than the webp equivalent and serves the more optimized image on the fly, with zero consideration. Since WordPress took a really long time to bring this to core, most of us have already used and ditched webp express and are already using Polish from cloudflare. Make it opt-in, please.

  6. WordPress stopped being a community project ever since Gutenberg was pushed down our throats, buggy and barely working. It’s only getting worse. Soon we will have 10-15 plugins disabling unnecessary features added by arrogant developers who don’t care about user’s needs and only care about their ill-conceived agenda.

    Maybe WordPress should start removing options from Settings, so we can install more plugins to disable features 🙄

  7. If project philosophy aligns with this approach, as stated by one of the team members in the article, then project philosophy needs to change.

    Some time ago, I said that Gutenberg should have been presented as an option, not an eventual mandate. The same is true here. It sounds as if WebP is not advantageous in all circumstances. Like other posters, I use Polish, which has the advantage of being more nuanced than the WP approach.

    Also, if WP commits to a particular format, it should ideally be one developed by a consortium rather than one company. Particularly if people connected in any way to Google are involved in the decision-making process, mandating a Google format could appear to be a conflict of interest, whether it is or not. “We should avoid not only evil, but the appearance of evil.” Cicero.

  8. I run a photo heavy blog, occasionally with 24-30 images per post. I size all images to the dimensions set in my theme and compress them manually to around 65% (or whatever suits the specific image).

    A couple of years ago I tried the WebP format and it was a disaster! The new format often didn’t result in any smaller file sizes, no, some were larger files.

    But since at the time not all browsers supported WebP images, the plugin created a “cache” directory that sat alongside my already large media library.

    So soon my database doubled in size, which
    a) exceeded my hosting account;
    b) and of course doubled my back-ups in size, so they required more hosting resources to run and occasionally failed halfway through;
    c) these backups logically also exceeded my off-site storage for them.

    Was I able to see any speed improvement? No, not at all!

    The opposite seem to happen because for every image there was a decision which one to include (or was it because the WebP cache wasn’t properly indexed and not sorted by post order?).

    Needless to say: I don’t want to repeat this mistake!

    • It looks like with all these smoke and mirror devices, devised to somehow satisfy the Google demand for some sort of speed/performance nirvana, that we have ended up with a jungle of Heath Robinsons. AI, complex caching that gets in tied up in a knot and, many other things that the human race doesn’t really need, where basic functionality would suffice. As you say Juergen, if you know what you doing you will size your media files correctly before uploading.

  9. After reading about this change, I checked a couple of client websites where the client had installed Imagify and enabled its webp setting.

    75%+ of the webp images were larger than the jpegs they were created to replace.

    Needless to say the webp setting was immediately disabled and I will be taking the plugin mentioned further up in the comments and converting it into a mu-plugin to be uploaded to all my client sites before upgrading to 6.1.

  10. This is sad day for page speed. All our test show that webP bloats the media library (uploads folder) on the server. And there is no speed benefit from webP from actual testing. A web myth. Smaller files loaded in parallel do not always equate to fast pages. Incredible sales job by Googles PR people.

  11. I’m using the Litespeed plugin on a client site, and the webP files are consistently smaller than JPG files. Usually around a 1/3 but sometimes even as much as 1/2. So for this site, it’s been well worth implementing webP and the Litespeed plugin handles it really well. Whether the native WP implementation will be good enough to replace Litespeed I need to check.

Newsletter

Subscribe Via Email

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