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

 Replying to [comment:143 adamsilverstein]:
 > We have completed a round of research on image sizes to investigate the
 best/any threshold for creating WebP images.
 > ...
 > Note that we are currently discussing the best compression quality to
 use for WebP on [https://core.trac.wordpress.org/ticket/54356 this
 ticket], and are likely to change the setting from the current 86 to
 either match the JPEG setting (82) or somewhere in between

 As far as I know older versions of the WebP encoding libraries may produce
 images with poorer quality when this is lower. Thinking perhaps it would
 be better to err on the side of the better quality and a bit larger size
 here to compensate.

 > To summarize, the research shows that across all image sizes, WebPs
 benefits far outweigh any adverse results (even for the current quality of
 86, and much more so for 82). Based on these averages, it makes sense to
 generate WebPs for all image sizes. The vast majority of generated images
 will be smaller, and the few that are larger will be only slightly
 larger.. Therefore, I don’t think we need a threshold filter.

 Thanks for looking at this again.

 > One addition to consider is enhancing `add_image_size` similar to what
 is proposed in https://core.trac.wordpress.org/ticket/56288. This would
 let developers opt out of the mime transform for specific sizes, so a
 newsletter plugin could add their own custom size that would always be
 JPEGs.

 Yes, think this makes sense for now. Eventually emails/newsletters will
 also start to support the newer image formats and this won't be needed but
 there may be other edge cases where forcing specific image format may be
 good.

 > To ensure compatibility for use cases where WebP may not be supported
 (OG tags, older safari and email), we can rely on the “original_image”
 meta when present (or the full size image when missing). Developers can
 use `wp_get_original_image_url` to retrieve the JPEG version.
 >
 > We may want to consider always creating a `full` sized WebP version of
 uploaded images to ensure we always have a “full” sized WebP (even for
 those below the `big_image_size_threshold`; above that size we would
 generate a WebP image already).  In this case, `original_image` meta would
 always be present.

 Thinking this will probably be more complex. When the uploaded image is
 larger than the "big image" threshold (2560px) WP creates a "full" size
 for use on the internet. When created by WP that full size should be WebP
 according to the above research. Perhaps it can be JPEG and used as
 fallback, but seems quite large. In addition it won't work for cropped
 image sub-sizes.

 On the other hand having the original image (regardless if it was made by
 WP or not) always be the same mime type as the uploaded image makes sense,
 and makes it quite easier for back-compat.

 When processing uploaded images the basic logic is:
 - Never change the originally uploaded image file except to rotate it
 according to EXIF.
 - If the image file is large, make a smaller version that's more suitable
 for use on the internet and set it as "original image".
 - If not too large, use the originally uploaded file as the largest size.

 To satisfy all fallback requirements without generating images on the fly
 it seems that it will need:
 - One image with the original ratio. Thinking perhaps a mid-sized image
 would work well here, perhaps the "large" 1024px.
 - A JPEG version for each cropped image sub-size. Alternatively all
 cropped images can be JPEG (thinking that's better?) or only some known
 sub-sizes can be WebP.

 > Regarding the inclusion of the infrastructure for multiple mimes: this
 would no longer be strictly required for only outputting WebPs.

 Yes agreed. The multi-mime support should be added from its own ticket
 where it can be researched/tested/reviewed easier.

 > Worth noting that the multi-mime architecture has been available/tested
 in the [https://wordpress.org/plugins/performance-lab/ Performance Lab
 Plugin]

 I think what's missing here is more docs/examples/explanations of how it
 is implemented and why. For example how is the image meta changed. How is
 backwards compatibility maintained, what ensures the changes are good
 enough when going forward, etc.

 > One enhancement I see is if we introduced multi-mime support along with
 async image generation, we could enable generating non-default mime types
 only when we need them, e.g. adding a `$mime_type` parameter to media
 functions, then generating the requested mime type if missing.

 Yes, definitely. If WP can generate image sub-sizes on the fly, I think
 most will be generated that way. Only one or two will probably be still
 generated on upload, likely the 1024px as it's used the most in the
 editor, and maybe the thumbnail.

 > Although I would love to see a larger refactor, that shouldn’t be a
 blocker for including this feature if we are confident of its value.

 I'm still thinking that it is a bit premature to add it now. It will be
 needed before adding more image formats for sure. It will probably also be
 needed to enhance and extend how WP handles JPEGs, PNGs, and WebPs in the
 future (eventual `<picture>` tag support, etc.). But think it will be
 better to add it when it is going to be used more widely both in wp-admin
 and on the front-end.

 > > This is starting to sound like a pretty good plan for this part of
 WordPress for the next few years. I hope we will be able to implement it
 well :)
 >
 > Based on this I will prepare two commits: one to revert the existing
 milti-mime commits, and one to introduce the WebP output change (so that
 it can be reviewed separately). Once this is in place we can follow up and
 evaluate if we want to add additional “full” size image handling, and
 update the shim we developed to swap out images for Safari.
 >
 > Thoughts?

 Sounds great :)

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