[wp-trac] [WordPress Trac] #55443: Create WebP sub-sizes and use for output
WordPress Trac
noreply at wordpress.org
Fri Jul 22 16:48:17 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-patch has-unit-tests needs-dev- | Focuses:
note needs-docs needs-user-docs commit | performance
-------------------------------------------------+-------------------------
Comment (by eatingrules):
Here's something that we discovered just yesterday on a new client's site.
I raise this because it's a very typical example of what we might see with
our clients.
This is a ''very'' popular blog (tens of millions of pageviews/month),
that has been around for many years. They have over 16,000 images in the
media library, and their uploads folder is currently >25GB.
They are supremely talented at creating great content, but they are not
"tech savvy" -- thankfully, they have the budget for an agency (and just
started working with ours). They had previously been been working with a
different, well-known agency. They are hosted on WP Engine.
We were having trouble getting backups to complete successfully (we use
ManageWP and Code Guard). In digging deeper, we discovered that the site
has many WebP images as duplicates of their JPGs. They're using Imagify
to create the WebP images and add the <picture> tags.
Additionally, most of the WebP files we looked at are significantly larger
(about 2-3x on average) than the original JPG.
I've downloaded a few samples from recent blog posts:
[[Image(https://p128.p0.n0.cdn.getcloudapp.com/items/Wnu7WE8Y/99251237-10e5-4ca5-8409-90cbe69879e3.jpeg?v=aa018c5435f632401581d909cd5470cc)]]
The site owner had no idea the site was creating WebP images (even though
it was "opt-in" on the Imagify settings! Someone must have turned that on
for them at some point), and they certainly did not know the WebP images
were larger than the JPGs.
(They also would not know how to add a filter to opt-out.)
We're now in the process of disabling the WebP functionality, and we will
be deleting all the WebP files once we've confirmed all is well without
them, so that our backups can work more reliably. (We'll then add in
Cloudflare Polish instead.)
I know the plan is to discard WebP images if they're larger than the JPG
(though see @jb510's point above)... but my point here is that the client
was completely oblivious that this was happening -- and they had the
advantage of having a support team to help them, on one of the most
popular WP hosting services.
Now imagine the mess that millions of site owners are going to find
themselves in when this is enabled by default without their knowledge...
and without any clear way to even disable it.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/55443#comment:76>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list