[wp-trac] [WordPress Trac] #55443: Create WebP sub-sizes and use for output
WordPress Trac
noreply at wordpress.org
Thu Aug 18 18:40:56 UTC 2022
#55443: Create WebP sub-sizes and use for output
-------------------------------------------------+-------------------------
Reporter: adamsilverstein | Owner:
| adamsilverstein
Type: enhancement | Status: assigned
Priority: normal | Milestone: 6.1
Component: Media | Version: 6.0
Severity: normal | Resolution:
Keywords: has-unit-tests needs-dev-note | Focuses:
needs-docs needs-user-docs needs-patch 2nd- | performance
opinion needs-testing |
-------------------------------------------------+-------------------------
Comment (by jb510):
Replying to [comment:115 azaozz]:
> Please do not commit any more code here unless it is to address the
dramatic increase of resources needed to create image sub-sizes after
upload. As I said above such increase is unacceptable.
>
> Is there any data about how much more resources (memory, processing
time, etc.) are needed when uploading different image sizes? Any estimate
about how many sites may be affected by that? Any suggestions on how to
deal with it? Do you know what happens when post-processing of an uploaded
image fails?
>
> Frankly for now it seems that this patch will have to be reverted and
refactored in order to address this.
>
I raised the issue of the UX impact at the time of image upload several
times (Slack and GH). few people seemed to take it seriously but then it
got mostly dismissed as OOS.
Initially:
https://github.com/WordPress/performance/issues/289#issuecomment-1114880692
Response:
https://github.com/WordPress/performance/issues/289#issuecomment-1126135778
Follow up:
https://github.com/WordPress/performance/issues/289#issuecomment-1126271943
When a user uploads an image the time spent waiting for sub-sizes to
generate. Yes, that is happening in the background, but they're still
stuck waiting on the upload screen. This is always created a bad UX, and
the time required waiting has doubled (someone verified this I think in
that GH issue or on Slack). Obviously, CPU impact is bigger, but I presume
that is a single-threaded/single-worker process. That probably not a big
impact overall on the site. But is in my opinion a big impact on the UX
from an author's point of view.
To me the existing sub-size generation is and has always been
fundamentally flawed. Generating dozens of thumbnails many of which
_never_ get used ought to have been addressed BEFORE introducing this
feature into core to literally double the number of thumbnails. Including
doubling the number of never used thumbnails. It just doesn't make sense
to keep charging forward on a flawed foundation.
We ought to be first finding a way to stop generating every thumbnail that
"might" get used someday and instead generate ALL thumbnails the first
time they're used and then cache/permanently store the resulting thumbnail
for the future use. Work has already been done on that approach, it has
just never got much traction on bringing it into the core.
It's also pretty easy to cause an out-of-disk space scenario with this as
is. The critical case should not be the 90% of sites on shared hosting, it
ought to be the cases like 100GB sites on DO/AWS/GC/etc.
I think the beneficial impact of implementing WebP by default on existing
sites also gets grossly over-estimated. Most existing sites have
hardcoded image links, to JPGs. A WebP existing isn't going to make old
content serve the WebP. Yet, these sites are going to get burdened with
even more never used thumbnails. It just doesn't make any sense to force
that.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/55443#comment:117>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list