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

 Replying to [comment:128 adamsilverstein]:

 Thanks for the reply!


 > I agree with your suggestion of only generating WebP format images.
 Also, I like the possibility of having a (filterable) “threshold” value
 above which (only) JPEGs are generated

 Great! Think this will make it faster and simpler.

 > One advantage of retaining some sizes is we can also use these JPEGs as
 fallback images for the edge cases where WebP still isn’t supported (eg.
 Open Graph tags).

 Yes, exactly. This will further simplify the implementation and improve
 image post-processing making it less likely to run out of memory/fail.

 > Given these points I can see two paths forward we should consider:
 >
 > 1. Keep the current multi-mime infrastructure, but change the defaults
 so only WebP files are generated, possibly up to a threshold size beyond
 which only JPEGs would be generated. Most existing work would continue;
 content filtering could possibly be removed.
 > 2. Revert the multi-mime infrastructure and switch back to a single mime
 approach, using WebP for images up to a threshold size and adjusting the
 compatibility layer to use the JPEGs we keep.
 >
 > When making this decision, we should also consider what is coming in the
 next few years: namely widespread AVIF support (support will land shortly
 in Safari).  If we might be adding AVIF support in a few years, would we
 want the multi-mime support then, or would the “single mime” output
 support suffice?
 >
 > My own inclination is to go with option 1 because of the pros listed
 above and the community process that led to the approach (and possibly I
 will admit some attachment to all the hard work that went into developing
 it). It works well, adds flexibility to media handling and sets us up for
 the future.

 Multi-mime support sounds pretty good, but also has some drawbacks. At
 first look it seems it's worth the effort to add now, but looking at the
 details, it adds a lot of complexity and possible bugs and edge cases. In
 addition it is a large update to most of the images handling code that is
 not critical for the current task at hand. As you said WebP image sub-
 sizes can be implemented without it, and the implementation will probably
 be simpler, faster, and with less edge cases/bugs.

 Images handling in WordPress is old, legacy code that has been fixed and
 enhanced hundreds of times over the last 15 years. It is pretty hard to
 work with and there are many chances of introducing edge cases and
 regressions. 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.

 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. Also, it would need a separate ticket. Thinking the
 current code is a great start, and it would need some more testing and
 polishing.

 > I recognize option 2 would be a much smaller change and would involve
 less risk and maintenance burden while still achieving the main goal of
 improving WebP adoption and hence lifting WordPress site performance. If
 we go with this option, we can still consider adding multi-mime support in
 the future, including the async “on demand” generation you suggested so we
 could actually improve upload success and user experience.

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

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