Category: Marketing

WordPress’ Performance team has put its WebP by Default proposal on hold after the community voiced critical feedback and significant technical concerns. The new feature would generate WebP images on upload by default for new JPEG uploads and would use WebP images by default for website content. WordPress’ Performance team proposed this update for the upcoming 6.0 release.

“The performance team has heard the feedback and takes the community’s concerns seriously,” Google-sponsored contributor Adam Silverstein said in an update on the status of the proposal. “With the help of the community, we will work on conducting additional data-driven research. Based on our findings, we will reassess our proposed approach to enabling WebP by default.”

Vocal opponents to the feature characterized it as “heavy handed” and pushed for it to be “opt-in” only or introduced with a more user-friendly way to disable it. One of the chief concerns is 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.

Viktor Nagornyy summarized storage concerns in a comment on the proposal:

This is not just about image formats. You’re going to drastically increase disk space usage by generating more images. This will affect anyone hosting WordPress on managed hosts with storage limit, their own servers with limited storage, anyone offloading images to S3, etc. This is why there needs to be an option to disable this under Media options. Hidden images generated by WP because of plugins and themes already cause problems. I’ve seen a site generate 20 images for every uploaded image. Uploads directory was 20GB. Can you imagine adding webp images in addition to this? 

This directly affects hosting cost. You will cause a lot of billing issues.

The Performance Team said they are working closely with the hosting community but this change directly benefits hosts that sell plans with tiered storage space limits.

“There are also significant conflicts of interest,” WordPress agency owner Andrew Wilder said. “WebP is a format that Google Created — and it’s Google Engineers who are leading the Performance Team. WordPress agency owner Andrew Wilder said. “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.”

Hosting companies may also experience complications as the result of enabling WebP by default that may not be worth the increased billing for customers who are forced to upgrade. Charles Smith, Managing Director at WordPress hosting company WPopt AB, articulated a litany of these concerns for hosts in a comment on the proposal, especially as it relates to support and backup costs:

Disk space – a vast majority of our users have very large image libraries. While they might not be hitting limits yet, effectively doubling the media library size is going to cause issues for many people. I can see that ending in one of several ways – either they’ll ask us to delete the webp files (so, more work for us, thanks!), or they’ll be forced to upgrade (so, higher fees for them), or they’ll get upset that we don’t offer more disk space for free, and then potentially leave us

Backups are already one of our major expenses. We invest in multiple solutions, and multiple storage locations. A decision like this will *directly* increase our costs. It will also make account restorations, account migrations and similar actions more time consuming.”

In the most recent update, Silverstein said the Performance Team’s primary objective in enabling WebP by default is to bring WordPress’ image processing to the level of its competitors.

“The main goal of this feature is to set the foundation for WordPress to be able to process and deliver more performant formats in the same way other CMS like Duda, Wix, and Shopify are already doing,” Silverstein said.

This reasoning is grossly disconnected from the concerns voiced by people who are in the trenches supporting and maintaining WordPress sites. The team’s initial approach at selling the benefits of WebP, without adequately addressing the disk space issue, has generated significant community pushback in a short amount of time.

As Performance Team representatives responded to concerns in the comments of the proposal, several participants in the discussion grew more irritated, saying they felt proponents of “WebP by default” do not fully grasp the real-world implications of the proposal for users. The timeline for bringing it into core also seemed rushed and premature, given that WordPress already has support for WebP images for those who choose to use them.

“Bottom line is pretty simple,” WordPress agency owner Sergio Scabuzzo said. “We are being asked to double the number of images for no good reason.

“There is a small bandwidth benefit in forcing all images to have a WebP version. But we will then have a crap show on our hands in the back end. How manageable are media libraries now? Cool, now double that with another media format. Oh, wait, let’s add AVIF later too…

“This is a problem looking for a solution, not a decision. This change is great only from a web crawler, search engine, supported device/medium. But for the WordPress ecosystem, it will create a huge headache in maintenance and hosting costs.”

The Performance Team is now reassessing its approach and seeking to bolster its case with more data and research. Silverstein referenced two GitHub issues where the team is tracking research on the impact of enabling WebP by default:

1. Research: Impact of additional WebP images on upload [Issue #289]
2. Research: WebP compatibility [Issue #290]

“Once we have completed our investigation and determined next steps on these two issues, we will work with the community to reassess two other concerns that were raised – having the feature on/off by default, and having a UI-based control to turn the feature on/off,” Silverstein said.

WordPress sites may soon see a slight performance improvement on page loads, thanks to a fix for a performance regression in the core lazy loading feature. An analysis published in July 2021 showed that lazy loading applied too aggressively can have a negative impact on performance and that it’s better to eagerly load the images within the initial viewport.

WordPress’ default of lazy loading all images was causing slower performance on the Largest Contentful Paint metric (LCP) metric, which Google defines as “the render time of the largest image or text block visible within the viewport, relative to when the page first started loading.”

Google-sponsored WordPress contributors wrote a fix that avoids lazy-loading images above the fold and thoroughly tested it as part of their efforts to evaluate the impact of various past performance initiatives. The delayed LCP will be fixed in WordPress 5.9.

“This can be improved by skipping addition of loading='lazy' for the first content image or iframe, which in the vast majority of cases will appear within the initial viewport,” Felix Arntz said in the dev note. “WordPress can only make educated guesses around that and not be 100% certain, but an analysis taking into account 50 popular themes showed that the enhancement brought LCP improvements across the board, up to 30% faster page load.” 

In the future, this implementation may be able to drill down further into the block content on the page and eagerly load whatever images the theme identifies as being within the viewport.

“Have you thought about how we could have more precise heuristics going forwards that can take the semantics and structure of blocks into account to get a sense for what is actually deferrable?” Matias Ventura commented on the ticket in process. “For example, an image block or a site logo used in a header template part would be strong indicatives of being above the fold. ‘The first image of the content’ seems instead like a rudimentary measure, that varies a lot depending on preceding layout. With block themes we should have some ahead-of-time awareness of layout which we can use to produce more meaningful instructions.”

Felix Arntz said he already has detecting the header template part on his radar and is willing to refine the implementation as the world of block themes expands.

“The refinement of the lazy-loading implementation should notably improve LCP performance for most sites that rely on it, while not having adverse effects for sites where the default heuristics described above do not apply to,” Arntz said. “That is only a solid starting point though. In the future, specifically with the more semantic content specification that block-based themes will facilitate, we will be able to further fine tune the lazy-loading implementation by using the available block information.”