[wp-trac] [WordPress Trac] #56263: Proposed WebP Generation in Core should be opt-in, not opt-out

WordPress Trac 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.


 **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.

 - 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 mailing list