[wp-trac] [WordPress Trac] #55443: Create WebP sub-sizes and use for output

[WordPress Trac]

#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