[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:118 adamsilverstein]:

 Thanks for the clarifications!

 > I tend to agree with your assessment that all sub-sizes should be
 generated as WebP only, that was the shape of the original proposal.
 > ...
 > The reason we decided to generate both formats was for backwards
 compatibility considerations

 Yes, makes sense. Seems it would be better to make these images "on
 demand". The advantages would be:
 1. Faster processing of uploaded images. This is critical.
 2. Reduced space requirements. JPEG images won't be generated unless they
 are needed.

 The "on demand" part can probably be handled by the code that would
 determine which image format to output.

 > The "multi-mime" support here is built to generating multiple formats so
 you sites can provide a primary and fallback format with something like
 the `picture` element. This is less important for WebP since it is so
 widely supported, but would be helpful for adopting newer formats like
 AVIF by plugins or core.

 To me it seems that the "multi-mime" support is not currently a critical
 feature. I agree, once the AVIF format gets wide support in the browsers,
 and in the image editing tools available in PHP, multi-mime support will
 be very desirable. But for now it doesn't seem needed.

 Also thinking that implementing  support for several image mime types
 would be best done as part of a larger refactoring of the images handling
 code. Perhaps even moving the image editing to the client and uploading
 the sub-sizes, and/or creating sub-sizes only when needed, etc. (I know,
 seems a bit far fetched, but one can dream, right?)

 > Generating images on the fly something we need to figure out but felt
 out of scope for this effort.

 Yes, it seems out of scope here. On the other hand it seems it will
 significantly improve this implementation. The first access of a
 particular image may be slowed down significantly (as it's being
 generated), but the space and processing time savings would bring far
 greater benefits.

 > Image sizes are complicated! On average, I have seen ~28% reduction in
 sizes for WebP version using current WordPress settings in lab testing and
 in the wild using httparchive data. That said, in some cases the WebP can
 actually be larger than the JPEG equivalent; for that reason the current
 code only keeps the WebP (or secondary mime) if it is fact smaller.

 Yes, you're right. I'm thinking more along the lines of having a "sensible
 mid-point" cutoff. Perhaps something like 800px or maybe 1000px. If an
 image's width and height are smaller, chances are WebP will be a better
 format for it. If not, make a JPEG. The advantages of such approach seem
 pretty good. Again, less space needed and greatly reduced processing
 time/resources (considering WebP images are not created and then deleted
 for the larger sizes).

 > I agree in general all sub-sizes should be generated, with the exception
 of sizes you know aren't for the front end.

 Yep, agreed.

 > Is it really a mess for the user though?

 What I mean is that there are some (subtle but noticeable) differences
 between JPEGs and WebPs when used on the web. A good example is that when
 a site visitor downloads an image, WebP will be a lot less usable than a
 JPEG. However the users/site visitors won't be able to tell which is
 which, hence some confusion.

 > You bring up a good point here though, there is a potential extra load
 cost to replacing these images that would be worth quantifying.
 > ...
 > Also, this would still be required for new content unless we make "only
 WebP" the default output.

 Yea, agreed. If the implementation is changed to generate fallback JPEGs
 on demand, that will be happening here, right? Then it makes sense to keep
 and even expand this imho.

 > This change also doubles the number of times WordPress will "retry" the
 image regeneration

 The problem is that "retry" for image post-processing doesn't work as well
 as expected. It is on my (ever growing) TO-DO list to revisit it soon,
 but... Not sire exactly when I'll get a chance. The bad news is that if
 the post processing fails, chances are the originally uploaded file will
 remain. Then it will be used everywhere as most of the code in WP falls
 back to available sizes, and the only size will be the original. That
 means we will be serving huge (4MB - 8MB average) images. A serious
 drawback.

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