Proposed WebP Generation in Core should be opt-in, not opt-out

[eatingrules]

The Performance team is working on implementing background WebP image generation and serving for newly uploaded images, targeting incorporation in core in 6.1 (and then expanding that to thumbnails in the future).

There has been substantial and productive community discussion about the proposed changes, regarding both the upsides and potential downsides:

​https://make.wordpress.org/core/2022/03/28/enabling-webp-by-default/
​https://make.wordpress.org/core/2022/04/12/follow-up-on-webp-by-default-proposal/
​https://make.wordpress.org/core/2022/06/30/plan-for-adding-webp-multiple-mime-support-for-images/

Currently the plan is to make this feature enabled by default for all sites, unbeknownst to site owners -- and disabling it would require a filter. (Most site owners don't even know what a filter is, let alone how to add one.)

We need more public/open discussion and decisionmaking on whether these new features should be opt-in or opt-out.

(Also needing consideration is a potential dashboard UI control to enable/disable the feature, rather than only by filter -- but that should probably be a separate ticket.)

While I agree that it's likely in most cases this will be a benefit for reduced bandwidth usage and improved site speed, I'm nevertheless concerned about downsides -- especially once all thumbnails are being duplicated to WebP.

The duplicated images will add up over time, and if a site owner regenerates thumbnails (which can happen deliberately, or unwittingly by some plugins), it could cause a massive increase in disk usage very quickly (which can also make backups and migrations more expensive/challenging).

Because of how this will roll out over time, I don't think we're likely to see significant issues right away -- but there will be an accumulation problem, especially for sites with large image libraries.

The Performance team's own research estimates that [​14% of sites might experience disk space issues over time. That's a lot of sites.

Jon Brown's (​@jb510) recent comment also ​sums up many of the concerns very well.

I appreciate the ​Philosophy of "Decisions, not Options" but we also need to consider the equally important philosophies of "Clean, Lean, and Mean" and "Striving for Simplicity."

Generating hundreds or even hundreds of thousands of additional image files is not "lean", and when things go wrong because of this (and they will), it will not be "simple" for site owners to understand or address.

I realize that if this is disabled by default it won't see rapid adoption. However, there are other ways to encourage adoption, such as an announcement on the "About" page after upgrading Core, or a dashboard notification. And, adding a UI setting would also make it easier for users to enable when desired (again, that's a separate conversation).

Thoughts?

[jb510]

TY Andrew for opening this ticket.

Echoing what I've said elsewhere. I too support core natively supporting new image formats like WebP and hopefully soon AVIF. Format support like this is definitely core territory.

My two concerns are how this impacts large existing sites (this ticket), and the delay it'll cause for authors "waiting for processing" when images are uploaded (the need for non-blocking background/shiny media uploads).

My concern with large sites is the likelihood that a user will naively or unintentionally trigger an operation that "regenerates thumbnails" and in doing so severely impact sites. Out of disk space is not a fun situation to unexpectedly encounter, nor is doubling a remote backup from 100GB to 200GB.

This isn't an issue on average sites, but WordPress' reach means we can't just think about "average sites". Repeatedly WP has taken the approach that it's not looking at 80/20%, but more like 99/1%.

Cases where this could easily happen:

• WooCommerce regularly prompts to regenerate thumbnails - 5m installs
• Regenerate Thumbnails (by Alex Mills) - installed on 1m sites.
• Dozens of other plugins that generate retina images, optimize images, cache plugins, etc.

The sane way to introduce this is to make it on by default only on new/fresh WP installs but make it opt-in on existing sites. Heck even put a prompt to turn it on on the splash screen. It just takes a single toggle on settings/media. It's not a complicated setting for users.

If not that, then a less attractive approach would be to make it opt-in for a least a few versions of WP until it's stable and well supported enough in the theme and plugin ecosystem to be deemed safe to enable by default. This approach has been taken before.

[blobfolio]

Thanks @eatingrules! I fully agree that these changes need to be opt-in rather than opt-out, especially for existing sites.

WebP is wonderful for lossy "good enough" photographic representation, but completely inappropriate for other contexts without intentional, manual tuning (and even then, sometimes it simply isn't the best choice).

I don't know why the magic bullet myth is so persistent, but NO image format — including AVIF and JXL — is so perfect it can replace all the others.

[costdev]

I personally use WebP on as many client sites as possible, but I agree that the feature should be opt-in.

Why?

Resource usage

• I've seen quite a few comments in recent months about this feature that state WebP are always smaller than JPEG. That isn't the case, and if testing results are showing that, the testing strategy doesn't reflect real-world cases. For example, when using any one of several plugins from the plugins repository, you'll see examples of larger WebP images on every website it's tested on. Note: A testing strategy should also include JPEGs already optimised via a plugin or a design package.
  • For the WebP files that are larger/virtually the same size, unless the feature checks the generated filesizes and deletes a larger WebP file, it's only going to create double the diskspace usage (at minimum) for those images.
• While this feature only targets subsizes, there are a significant number of image-heavy websites (e-commerce, etc) that already use a sizable portion of their hosting plan's quota. The potential negative impacts in terms of downtime, hosting and support costs is too much to make this feature opt-out.
• The generation of additional formats will significantly increase the resource usage - particularly when bulk uploading.

Philosophy

• This feature can make a really positive impact on many websites, but it also comes with significant drawbacks. IMO, it would be much better to have users opt-in to a feature they might find beneficial, rather than ask them to either:
  1. Delete all of the generated WebP images via FTP and add some lines of code to disable the feature going forward, after either seeing performance issues during image (re)generation, or running out of diskspace on their hosting plan.
  2. Pay an agency to do the above.

• Expecting hosts to determine whether the feature should be enabled on their systems isn't realistic - they won't know what their customers are planning for their first site, or their next site(s). For unmanaged WordPress installations, this is too unpredictable and will only lead to support requests to enable the feature again. This could lose hosting companies customers, increase their support costs, or worse, force hosting companies to only support WebP on their more expensive hosting plans that have more diskspace - effectively making a Core feature pay-to-win.
• "Decisions, not options" is an important part of the WordPress philosophy, but for this feature, it's generally been mentioned in the context of making this feature opt-out. However, "Decisions, not options" is about making the right decision on behalf of users, whatever that decision might be, when appropriate. This feature is simply too risky to be opt-out.

Precedence

• We have media settings for splitting folders in year/month or not and for thumbnail sizes. If we expect site owners to be able to understand the impact of these settings (not to mention Permalinks, pingbacks, threaded comments, etc), then we should have no issue with offering one additional option such as:
  • Media Format
    • JPEG (Default) - Well supported, but typically has larger filesizes.
    • WebP (Recommended) - Not as supported as JPEG yet, but typically has smaller filesizes.
    • JPEG and WebP - Maximium support with minimal filesizes, but will use more diskspace on your hosting plan.

From a developer's perspective (both Core and client-facing), I'm not concerned about the technical requirements for developers to enable/disable this feature on sites where appropriate. I'm concerned about site owners who aren't paying an agency, are on low resource hosting plans, have restricted finances or have very limited technical knowledge. We have various ways to make this opt-in (Settings API, filters, constants, etc) and until WebP has wide enough support to be considered for default, this feature should only be enabled through an informed decision.

I'm happy to discuss this feature further, including to correct any misunderstandings I may have (feel free to ping me on Slack - same username). Until then, if opt-in is a no-go, I think the feature should be revisited with foreknowledge of opinions from a wide range in the hosting community, agencies and extenders. Typical performance gains alone aren't enough to justify opt-out IMHO.

[imarkinteractive]

I echo what was laid out by @eatingrules here. While we have no issue with setting up automatic webp generation on upload for new images, it should definitely be opt in. Most of my customers do not know how to add a filter and most bloggers don't know how to do it. You are assuming they have the skills to put in a filter.

The number of large sites with thousands and thousands of images is actually larger than I believe has been identified and you would be surprised how many times someone might regenerate thumnbnails for a plugin change, new theme, etc. We actually deal with this process daily so it's an issue.

Sites that have been blogging since 2008 might have over 100,000 images with many different thumbnails sizes and it shouldn't be on them to put in a filter to stop this processing. They should have to put one in if they want to process them.

[codekraft]

Replying to blobfolio:

WebP is wonderful for lossy "good enough" photographic representation, but completely inappropriate for other contexts without intentional, manual tuning (and even then, sometimes it simply isn't the best choice).

I don't know why the magic bullet myth is so persistent, but NO image format — including AVIF and JXL — is so perfect it can replace all the others.

I'm sorry but I have to contradict you--the new formats are vastly superior--they wouldn't have created them if they weren't!

the problem lies in compressing already compressed images (introducing generation loss) but I think it is undeniable that webp and avif and jxl are much better than png and jpeg.

Starting from a 50% compressed jpg image (as i have seen myself doing) you can't expect to have good results because what you are compressing is the version already heavily pixilated from the jpg compression to which you are going to add other artifacts, one thing that is important is that the original should not be "pre-optimized" (on the contrary a lossless would be better). This problem is partly corrected by the fact that webp larger than jpg are removed (​https://github.com/WordPress/performance/pull/418)

[jorbin]

Rather than a new ticket, the conversation should be centralized on #55443 where the webP feature is being implemented. This is not an attempt to shut down this conversation, but rather to make sure that all of the information for the feature development can be centralized.

Also, a reminder that repeating the same argument over and over is dilatory. That's not to say you shouldn't present new information if you have it.

[eatingrules]

@jorbin I started a new Trac ticket specifically because @adamsilverstein asked me to:

https://core.trac.wordpress.org/ticket/55443#comment:62

If we can't even agree on how to discuss this, how is a reasonable decision going to be made?

To your point, though, many people (myself included) are making similar arguments in multiple places because it seems that the performance team is not properly taking them into account.

So we've had no other choice but to leave comments on the many blog posts and Trac tickets. This ticket is an effort to consolidate the decision-making for one very critical -- and controversial -- decision.

[jorbin]

Duplicate of #55443.

I disagree with @adamsilverstein on the new ticket idea and we ​discussed it in #core slack. Thank you for bringing it up.

The centralization is so that code archeologists in the future (AKA the contributors of tomorrow) can more easily understand all of the discussion without needing to jump around between multiple places.

[eatingrules]

Got it, thanks @jorbin.

(also, "code archeologists"... 🤣 I love it!)