[wp-trac] [WordPress Trac] #56263: Proposed WebP Generation in Core should be opt-in, not opt-out
noreply at wordpress.org
Fri Jul 22 04:36:57 UTC 2022
#56263: Proposed WebP Generation in Core should be opt-in, not opt-out
Reporter: eatingrules | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Media | Version:
Severity: normal | Resolution:
Keywords: 2nd-opinion dev-feedback | Focuses: performance
Changes (by costdev):
* keywords: => 2nd-opinion dev-feedback
I personally use WebP on as many client sites as possible, but I agree
that the feature should be opt-in.
- 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
- 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
- The generation of additional formats will significantly increase the
resource usage - particularly when bulk uploading.
- 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.
- 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
- 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
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.
Ticket URL: <https://core.trac.wordpress.org/ticket/56263#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac