[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 changes-requested        |
-------------------------------------------------+-------------------------

Comment (by adamsilverstein):

 == Research on WebP Sizes
 We have completed a round of research on image sizes to investigate the
 best/any threshold for creating WebP images. In summary, the research took
 a sample group of images, ran them through WordPress sub-sized image
 generation, then output data about the WebP and JPEG version’s file size
 to a spreadsheet (see
 [https://docs.google.com/document/d/1CDEkBD2wFlrAmnmqLthg9XB5qzHAtUe5HpCDHpo3Ln0/edit?usp=sharing
 summary of results] and this [https://github.com/mukeshpanchal27/webp-
 quality-analysis repo branch] with testing code).

 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 (e.g. 83 or 84 or...). For
 that reason the research was conducted repeatedly with WebP quality
 settings of 82, 84 and 86.  For my comments below I am using the numbers
 from the 82 setting. Regardless of the quality setting though, the
 conclusion is the same.

 With quality for WebP set to 82: for all image sizes, the average savings
 for WebP was ~36% and only 4.75% of generated WebPs were larger than the
 equivalent JPEG . In those cases, they exceeded the JPEG size by an
 average of 3.75% and maximum of 9.64% (and an even lower 6.25% maximum for
 large images). For comparison, the savings at 84 quality averaged ~29%,
 with 7.19% being larger; at 86 quality the savings averaged ~23% with
 around 16.99% being larger. In all cases though, the large savings for
 most images outweigh the small increase for a small percentage of images.

 == Conclusion
 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. Is there a
 use case for it I missed?

 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.

 == JPEG for compatibility
 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.

 What do you think?

 === Additional questions

 Regarding the question from @costdev
 > Query: If I, for example, upload a JPEG that's 1024x1024 and 512KB, and
 the feature creates thumbnails, does that mean that the 1024x1024 and
 512KB JPEG would be used as a fallback if WebP isn't supported, even if
 the display size is 150x150?

 True, however the JPEG would only be used for ~2% of Safari users.  For
 Open Graph tags, the consumer site will likely create its own sub-sized
 front end variations. Email or newsletter platforms probably/can do the
 same, we can test that to make sure.

 This was part of the issue multi-mime format generation aimed to address.
 If WordPress generates both WebP and JPEG,  we can provide maximum
 compatibility - Safari users could always count on getting a similar sized
 JPEG as a fallback. The trade off here is increased file storage and
 upload processing cost to generate the extra images and we previously
 decided that trade off was worth it. For reference this is the original
 [https://github.com/WordPress/performance/issues/96 issue] where adding
 multi-mime support was discussed.

 == Infrastructure
 Regarding the inclusion of the infrastructure for multiple mimes: this
 would no longer be strictly required for only outputting WebPs. Still, the
 multi-mime feature does offer some advantages worth considering: mainly
 the ability for site owners to maximize compatibility by always having a
 jpeg version of every size (at the expense of work at upload time).

 > Also I think it would be better if the multi-mime support is added after
 wider testing. For that it would be great to try to make it into a feature
 plugin if possible

 Worth noting that the multi-mime architecture has been available/tested in
 the [https://wordpress.org/plugins/performance-lab/ Performance Lab
 Plugin] (which is a collection of performance features being testing for
 core) since it's initial release  and with over 10k installs. Not sure
 this addresses your concern about added complexity, but this is definitely
 getting some widespread testing already!

 >  I think that adding multi-mime support would probably be better as part
 of a larger re-imagining/refactoring of how WordPress works with images.

 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.

 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.

 > Yes, exactly. In my mind this is the right approach. WebP by default can
 be added now. Multi-mime support can be added in the near future, most
 likely before it is needed for supporting AVIF. Ideally by then WordPress
 will be able to generate image sub-sizes on the fly as needed.

 > 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?

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