[wp-trac] [WordPress Trac] #55443: Create WebP sub-sizes and use for output
WordPress Trac
noreply at wordpress.org
Wed Aug 31 22:02:02 UTC 2022
#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
More information about the wp-trac
mailing list