[wp-trac] [WordPress Trac] #55443: Create WebP sub-sizes and use for output
WordPress Trac
noreply at wordpress.org
Thu Aug 18 18:48:44 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 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
More information about the wp-trac
mailing list