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

 Replying to [comment:152 adamsilverstein]:
 > > stopping the needless generation of never used thumbnails just because
 the size definition was added
 >
 > The tricky part there is knowing which images are actually needed.
 Waiting until they are requested probably requires `.htaccess` changes,
 which while possible, will not work for all setups. We might be able to
 improve on that, perhaps we can combine some knowledge from the block
 editor (and its breakpoint driven previews) to derive the images we expect
 to need.
 >
 > What do you see as the main problem with pre-emptively generating all
 sizes, primarily a storage concern? Certainly something to consider, but
 challenging to build in a way that works across WordPress installs.

 Storage (KB and file count) and CPU cycles.  I think absent from this
 conversation is that every KB of storage is actually 10-20x that much when
 you take backups into account. Now, I'd prefer versioned backups that
 don't store really-big-image.jpg uniquely in ever single backup, but most
 don't do that.  File count because at scale it affects performance.  CPU
 cycles because while "cheap" in this context that too affects performance.
 All together, all this also has an avoidable environmental impact.

 htaccess is one way, but I imagine a JS based worker could handle it as
 well independent of server config.


 >
 > > Click on the “relative usage tab” to get a good visual
 https://caniuse.com/webp
 >
 > Neat, I hadn't seen this before.
 >
 > > mobile safari running on iOS 13 and earlier, that’s a tiny number that
 probably should be given some consideration if only because serving a
 larger fall back on mobile would be very bad practice.
 >
 > this would suggest keeping a much smaller size as JPEG, right?

 See my comment immediately above. Looks like 1.18% for iOS without WebP
 support. MacOS certainly can be completely ignored, but 1.18% for older
 iOS devices seems significant.  I loathe the idea of a JPEG for every
 thumbnail size and am _very_ happy we've moved away from that.  I don't
 love the solution, but generating 1 full size jpeg and serving that
 anytime a jpeg fallback is needed seems like an option.  The problem with
 that I imagine is dealing with the various hard/soft crops. To me, the
 right solution remains, only generate the JPEG if/when it's actually been
 requested.

 >
 > > Comparing SSIM is a bit more complicated than just looking at file
 size but there is data out there on this.
 >
 > yes, we wanted to repeat the studies in a WordPress context though,
 since our image generation stack is somewhat unique.

 Well, "WordPress context" means a user has uploaded an image with anywhere
 between 50% quality and 100% quality.  You just never know...  But the
 photographers most concerned already dislike t
 >
 > > I do think you need to generate a full size image (not original) in
 jpeg format as a fallback. Just one though. I then think there ought to be
 a filter to enable generating Jpegs of all sizes, vs the default 82% jpeg
 quality feelings it's too aggressive (I disagree, but such is the case
 with subjective opinions).   My point is simple that is a 100% jpeg gets
 uploaded, the WebP is going to come out much better than the jpeg if both
 files end up being 200KB. The SSIM score on the WebP will be way closer to
 the original than the jpeg will be.  Anyway, think it's been discussed ad
 nauseam. I don't think we need jpeg fallback because in a tiny number of
 cases they're larger than jpegs.

 This is a good example of decisions not options. Making decisions (webp
 only thumbnails) is great when it actually simplifies things for the end
 user.  Users shouldn't be concerned whether their thumbnails are jpeg or
 webp, just that they work.

 >
 > Right, we have discussed this before, maybe adding a new full-original-
 mime "size".
 >
 > > I still feel needs a user facing checkbox on the media setting page
 for “Enable modern image format conversion [ ] WebP [ ] AVIF, etc.., With
 those off by default on upgrades for at least a few versions, and on by
 default on new installs.
 >
 > I don't agree we need a checkbox, to me this would be confusing for
 users.


 The problem with saying "decisions, not options" here is that it's being
 misapplied (in my opinion) when is about not providing a very simple and
 useful option from the user. In this case enabling/disabling specific
 image format support.  That's a single checkbox that does something
 simple. The alternative here, a filter and/or plugin to effect a filter is
 WAY more complicated.  You're actually forcing a very complicated solution
 on users to avoid a single check box.  Decide to provide a simple option,
 instead of deciding to force a complicated one.

 I don't see how this would be a consuming option. It's a check box that
 says "do you want WP to convert your images into a more performant format,
 WebP.  A lot of users are going to say "no, I want to keep using JPEGs"
 for whatever reason.

 Again, in terms of the 99% impact debate.  Sites with old images aren't
 going to benefit from WebP at all, because those images are hard-coded
 URLS pointing at jpegs. It's wildly wrong to presume existing content will
 benefit from WebP. Keep in mind just how recent blocks are and how little
 content has been built with blocks vs the classic editor. However, all
 most new content going forward will benefit!

 I believe @eatingrules concern is that WebP images are still going to be
 generated for existing images, images that already have JPEG thumbnails.
 So if I have an existing media library that is 100GB, what is the impact
 on regenerating thumbnails on that library the day after this launches?

 If WP was smart enough to only generate images that were actually
 requested, this would be non-issue.  But if WP is going to say "well I
 need to generate webp thumbnails of every old image just in case someone
 inserts it in the future", that's the problem.

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