[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 adamsilverstein):

 @eatingrules thanks for the questions, answers below inline...

 > How will dealing with thumbnail regeneration work?

 By default, regeneration will use the current generation scheme, so you
 would get new WebPs as you suggested.

 If space is a concern: to avoid extra files, you could either use the
 'delete previous images' option in the Regenerate images plugin, or
 disable WebP before regenerating images (for example, with this plugin
 https://wordpress.org/plugins/disable-webp-by-default/). For the specific
 case of woo commerce, they may want to consider an option for disabling
 WebP output for their regeneration code.

 Are you aware of any other plugins that regenerate images?

 > Could you maybe share some sample images from the tests so we can get a
 sense of the visual quality loss (if any) for each of the compression
 levels?

 I can dig up some or file names at least. You could also re-test with your
 own set of images using the tool.


 > What about images other than photos?

 Image quality testing provides a spectrum of results based on the input
 and we don't have any data on what users actually upload.  We picked
 images that were mostly hires photos, something that is very common on the
 web. You will get different results testing images like line art, drawings
 or logos, however my guess is you will still see an overall improvement in
 WebP sizes.

 Line art should probably be SVGs. Logos and product images are typically
 served as PNG images on the web today because of the alpha transparency
 capability. WebP makes a much better format for these images because it
 supports lossy images with alpha transparency, something that isn't
 possible with JPEG. Compared to a transparent PNG, the WebP lossy
 compression version will save ~80%!


 > What happens when users Right-Click->Save as, and they get a WebP
 instead of a JPG?

 Those saved WebP images will be slightly less usable (presumably, some
 programs still don't support WebP). Really though, this isn't much
 different from what happens when you save an image from your iphone in
 HEIC format (which is arguably less compatible). The same will be true of
 any new format and this shouldn't stop us from adopting them. Ultimately,
 I expect the user agent (eg the browser) to provide a 'save as' option
 (similar to other programs), so users can get a JPEG if they need one.


 > Is the plan still for this to be enabled by default?

 Yes, it doesn't make sense to introduce a new feature that is not enabled.


 > Will there be any user interface for turning this on or off?

 No. I have yet to see a strong argument for having a UI. I remain open to
 considering it, although as previously mentioned, project philosophy
 strongly suggests no UI. Also, this question remains: would average users
 know how to choose the best option? Instead, users can install a plugin to
 disable the feature, see https://wordpress.org/plugins/disable-webp-by-
 default/.


 > What happens to existing images/thumbnails when it's enabled? Disabled?

 Nothing. This feature only effects the __generation of images__, no change
 is made to existing media.

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