[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 2nd-opinion needs-  |  performance
  testing changes-requested                      |
-------------------------------------------------+-------------------------

Comment (by jb510):

 Replying to [comment:147 adamsilverstein]:
 > > Did someone mention on the fly image generation!? I wrote a blog post
 on this and provided a proof of concept in 2017. I even packaged it up as
 a plugin and published on WordPress.org as per Matt's request in the
 comments.
 >
 > Hey @bradt nice to see you here!
 >
 > The performance team has reviewed your post and plugin as part of the
 inspiration for what we are working to build for core. As you suggest, the
 idea is a new API for background tasks (A "background queue") and the
 first direct use of that API in core would be async media generation
 (https://core.trac.wordpress.org/ticket/6814).
 >
 > With this in place, user experience uploading images would greatly
 improve. We could show them a thumbnail immediately (uploading images in
 the block editor does this already), then generate the sub-sized images in
 the background without requiring the presence of the user agent.
 >

 @adamsilverstein apologies for being a little OT, but is there a ticket
 for that background image processing queue? The most important thing many
 have expressed is stopping the needless generation of never used
 thumbnails just because the size definition was added.  I’m really hopping
 this is being taken into account and it’s not just preemptively generating
 all sizes in the background.  We used Brad’s solution for many years on
 several large sites with great success.  Ironically the reason we stopped
 was we adopted WebP.

 I feel support for WebP keeps getting understated, or that the lack of
 support given undue concern.  The only two places it’s not supported are
 Safari when running on an earlier version of MacOS than 11.  That’s a tiny
 number I think can be ignored.  And mobile safari running on iOS 13 and
 earlier, that’s a tiny number that probably should be given some
 consideration if only because serving a larger fall back on mobile would
 be very bad practice.

 Click on the “relative usage tab” to get a good visual
 https://caniuse.com/webp

 Threshold - i didn’t see it get discussed but WebP preserves more detail
 at the same file size than JPEG assuming you start with an uncompressed
 high detail source image.  Comparing SSIM is a bit more complicated than
 just looking at file size but there is data out there on this.   Basically
 if you start with a medium compressed JPEG that detail is already gone and
 converting to WebP you end get the same file size, but also the same
 degraded quality.  Taking a raw image source image and then look at SSIM
 between a WebP and JPEG compressed to the same file size, WebP looks
 better.  Anyway, I agree, thresholds don’t make sense at this point.

 I do think you need to generate a full size image (not original) in jpeg
 format as a fallback. Just one though.  I then think there ought to be a
 filter to enable generating Jpegs of all sizes, vs the default which
 should just be the full size.  Unlike enabling the feature entirely which
 I still feel needs a user facing checkbox on the media setting page for
 “Enable modern image format conversion [ ] WebP [ ] AVIF, etc..,   With
 those off by default on upgrades for at least a few versions, and on by
 default on new installs.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55443#comment:149>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform