[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 needs-patch 2nd-    |  performance
  opinion needs-testing changes-requested        |
-------------------------------------------------+-------------------------

Comment (by eatingrules):

 Replying to [comment:139 azaozz]:
 > Thanks for sharing! This is exactly the feedback that's needed here
 IMHO.

 You bet. I'm incredibly grateful you've jumped in here, too. Thank you.

 > It would be great if you could post some aggregated data and perhaps
 some (estimates) on how storage requirements change after installing an
 image optimization plugin, or perhaps how much more space is taken by the
 WebP images.

 In previous conversations, I think the rough estimate has been that WebPs
 are about 70% the size of JPG (on average)... so the proposal (before the
 recent threshold change), would likely increase image library sizes by 70%
 (assuming thumbnails get regenerated at some point).

 So.. if someone has, say, a 10GB folder of images, that would turn into
 roughly 17GB.

 For our clients, we don't have these plugins create WebP images -- we just
 optimize the existing files (JPGs stay JPGs) and keep the originals in a
 backup folder. I don't have an easy way to aggregate data, but I can at
 least try to find some representative samples of the upload folder size
 vs. the Shortpixel/Imagify Backups folder sizes. I might not be able to
 get that done until the weekend, but I'll follow up with that ASAP.

 The sheer number of files is a concern as well...Hosts often have inode
 limits in individual folders, and some also implement overall limits on
 the total number of inodes.

 (To be fair: it's rare for us to run into these inode limits, as we're
 generally working with higher-level hosting. I'm guessing that would be
 more of an issue on lower-budget, shared hosting plans.)

 Another example: We use ManageWP as one of our backup tools; it has a
 limit of 1 Million files per backup/site. We're actually struggling to be
 below that threshold right now on a site we recently started working
 with... they don't have any WebP files and we've excluded the Shortpixel
 backup folder.

 And it'll be especially bad if a user does not have "Organize my uploads
 into month- and year-based folders" enabled. (Now ''that's'' a setting I
 would like to see go away! 😆)


 > Also the current proposal is to not create duplicate images at all.
 Instead there would be a threshold. Smaller sizes will be WebP as it seems
 that's most efficient there. Larger sizes will continue to be JPEG. These
 larger sizes will also be used as fallback where WebP is not supported.

 I believe the Performance Team's original proposal was to do this (though
 without the JPG cutoff threshold), and it was met with some significant
 resistance as well.

 Reading the comments on these posts may be helpful if you haven't seen
 them yet:

 https://make.wordpress.org/core/2022/03/28/enabling-webp-by-default/
 https://make.wordpress.org/core/2022/04/12/follow-up-on-webp-by-default-
 proposal/

 I do think the current plan you referenced could work, and be of
 significant benefit to many sites while mitigating the possible negative
 impacts, if all of the following are true:

 **1. It's opt-in, not opt-out.**
 **2. The site owner is made aware of the pros/cons before enabling it.**
 **3. There is an easy setting (not just a filter) to turn it on/off.**

 This way, if the site owner finds there's an issue, they will (presumably)
 understand why and could turn the feature off.

 There would still be some other challenges to overcome, though. A few off
 the top of my head:

 If it's turned off, how would it revert gracefully? Would they have to
 regenerate thumbnails?

 What would happen when they turn WebP on and then later regenerate
 thumbnails? If the system then generates WebP thumbs, but doesn't delete
 the old JPG thumbs, we may have similar (and very sudden) disk space
 issues.

 One idea to solve that could be to delete all the old JPG thumbnails as
 the WebPs are generated, but that would likely cause other issues. For
 example, if JPG thumbs are indexed in Google Image Search, or linked to
 directly from other sites, there could be many broken links.

 Format conversion behind-the-scenes can also confuse users. I shared this
 earlier in the thread:

 > We use Cloudflare Polish for our clients' sites, which will serve WebP
 if it's smaller than the original JPG... our clients (or their Assistants)
 will try to download an image from the front-end of the site. So they'll
 Right-Click->Save As... and then be very confused and frustrated when the
 file that they think is a JPG actually downloads as a WebP.

 One last anecdote for now:
 [https://wordpress.slack.com/archives/C02KGN5K076/p1651851856774209 Here's
 a story I shared in Slack in #core-performance last May], about a client
 whose site was generating WebP images (due to a performance plugin
 installed by his host), and he was unaware. It was an SEO disaster when he
 changed hosts, ultimately costing him many thousands of dollars of lost
 revenue. It's another example of how there can be catastrophic unintended
 consequences to these changes, which is why I think it's best to tread
 lightly.

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