[wp-trac] [WordPress Trac] #56263: Proposed WebP Generation in Core should be opt-in, not opt-out
WordPress Trac
noreply at wordpress.org
Thu Jul 21 00:15:48 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 | Keywords:
Focuses: performance |
-------------------------+-----------------------------
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
[[https://docs.google.com/document/d/1_si5UPkjC9R5yPPL6FPWfx7jahB8GPb2lrxGpdigYDM/edit
14% of sites might experience disk space issues over time]. That's ''a
lot'' of sites.
Jon Brown's ([https://profiles.wordpress.org/jb510/ @jb510]) recent
comment also [https://make.wordpress.org/core/2022/06/30/plan-for-adding-
webp-multiple-mime-support-for-images/#comment-43278 sums up many of the
concerns very well].
I appreciate the [https://wordpress.org/about/philosophy/ 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?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/56263>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list