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


 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