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

Comment (by adamsilverstein):

 @azaozz - thanks for the review and feedback, responses inline below.

 > > This ticket introduces the capability to generate more than a single
 mime type. For example, when users upload JPEG images, WordPress can
 automatically generate both WebP and JPEG sub-sized images.
 > Like @MatthiasReinholz, @eatingrules, and others I think this approach
 is perhaps lacking. Why would there be twice as many image files taking up
 a lot of extra space when half of them will never ever be used anywhere?
 > IMHO a better approach would be to just make all image sub-sizes WEBP.

 I tend to agree with your assesment that all sub-sizes should be generated
 as WebP only, that was the shape of the original proposal. For the vast
 majority of use cases/users this will work the best. I would be open to
 considering this for the default (with some mitigations, see below).

 The reason we decided to generate both formats was for backwards
 compatibility considerations for the few edge cases we identified where
 WebP images will might not work: namely emailed images (some older
 outlook/windows clients), Open Graph tags (some services don't support
 WebP) and older Safari browsers. One possibility we considered would be to
 keep only the full sized JPEG so it is always available for those edge
 cases.

 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.

 > If JPEGs are indeed needed, these can be generated on-the-fly as needed.
 There is no point of clogging the web servers storage with all these
 useless files.

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

 > On the other hand, if the WEBP file sizes are actually larger than the
 JPEGs, that would probably mean that better tools are needed, and this
 patch is premature.

 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 equivelent; for that reason the current
 code only keeps the WebP (or secondary mime) if it is fact smaller.


 > BTW, this functionality (making all sub-sizes WEBP) has been available
 in WordPress for a few releases. Is there any data to how much it is used,
 and how well it works. Think such data would be crucial in deciding
 whether to keep working on this for now.

 We don't have data about how much this exact feature is used, but we do
 have data about how many WordPress site pages use WebP images by WordPress
 version (and the average weight of those images). I am attaching
 screenshots of the report I created, the main query I used is
 [https://gist.github.com/adamsilverstein/6a7619f8dd5233e707eea484a08e8151
 here]. This data tells us that WebP is increasingly being adopted by
 WordPress sites, even though this currently requires installing a plugin
 or manually generating WebP images before uploading them.


 > Another shortcoming seems to be that only some image sub-sizes will be
 converted to WEBPs. Not sure why, doesn't seem to make sense?

 I agree in general all sub-sizes should be generated, with the exception
 of sizes you know aren't for the front end. For example, if you created a
 256x256 pixel logo for your OG tag, you might want to opt that image size
 out of generating a secondary (or alternate) mime type.


 > Then the users will end up with a "soup" of images, some different
 sizes, some identical sizes but different formats. Why the mess? :)

 Is it really a mess for the user though? I can see with your media
 developer hat it is a bit messy, but for end users nothing actually
 changes in the UI or when using images. The meta data accurately reflects
 the available images, and deleting the image correctly deletes all the sub
 sizes. Naming conflicts have also been carefully addressed. Even
 currently: if you edit an image in media, the filenames all have a hash
 appended and after multiple edits you end up with many hashed files making
 a "mess".

 > Another thing that seems to not make sense is the idea to replace images
 by default. Why would this be needed? Only newly uploaded images will have
 WEBP sub-sizes, right? Then they will be used when composing new content,
 right? Why would WP spend so much resources looking at places where old
 images are used?

 The would be used for new content if they were the only type, but since we
 are keeping both, the original type (JPEG) will be used in the content by
 default. An additional consideration is image regneration - if users
 regenerate their past images, the secondary type would be generated (WebP)
 and the on the fly replacement will upgrade their past content images as
 well.

 You bring up a good point here though, there is a potential extra load
 cost to replacing these images that would be worth quantifying. Worth
 noting that this work takes place in the context of existing per-image
 content processing in `wp_filter_content_tags` where we already prime
 caches on the attachment IDs (so the cost should be low).

 > (I understand, given enough storage space some users will probably
 "regenerate images" and create WEBP sub-sizes. But this will be the
 exception, not the rule. Such exception should be handled by a plugin.
 Doesn't seem a good idea to slow down millions of sites just because of
 that possibility.)

 We can investigate how much this slows down sites. As I mentioned, the
 meta call should return cached data and one of the very check looks for
 `empty( $metadata['sources'] )` - returning early in that case.

 Also, this would still be required for new sites unless we make "only
 WebP" the default output.


 > > Resources for generating images when you upload an image will increase
 dramatically, however resources to serve an image...
 > Actually that dramatic increase of resources usage when uploading an
 image is a very bad side effect here. It means a lot of uploads will fail,
 and leave the users stranded. It also will increase support requests for
 both WordPress and the hosting companies dramatically. Don't think this is
 acceptable. Because of this, even if image multi-mime support is needed in
 WordPress, the current approach doesn't seem like a good solution.

 This change also doubles the number of times WordPress will "retry" the
 image regeneration, so while processing time will increase, I don't think
 we'll see a jump in failures necessarily. I know we had trouble adding new
 sizes in the past, however that was before we added the retry mechanism.

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