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

Comment (by eatingrules):

 Replying to [comment:164 azaozz]:
 > It's true that "many people have been calling for this" on GitHub and
 Trac, but consider who these people are. Web Developers or otherwise
 engaged in the development of WordPress. A good rule-of-thumb would
 probably be to ask few people that have nothing to do with software
 development, like perhaps family and friends. Would be good to see what
 they know about WebP and its advantages and disadvantages :)

 Thanks again for jumping in on this. I couldn't agree with you more -- and
 that's exactly why I've been pushing back so strongly. I am particularly
 well-qualified to represent the WordPress users who have nothing to do
 with software development. I know them well; I've built my entire business
 on [https://www.nerdpress.net/testimonials/ helping them].

 To be clear, I'm not fundamentally opposed to WebP. I understand the
 positives here. Smaller images are better. I also get that for most sites,
 this will be beneficial and likely not cause issues.

 But there will be negative consequences for a very significant number of
 sites -- and those consequences have not been addressed sufficiently.

 It has also felt like the Performance Team is going to barrel ahead no
 matter what, and now the ONLY possible thing we have left is to try to get
 it to be off by default and/or have a UI component. It's a hail-Mary pass,
 frankly.

 With the current proposal, the user will be completely unaware of that
 this is now happening on their site, and that will actually make the
 likelihood of issues even greater.

 However, I know from experience with our clients that the vast majority of
 "non-technical" people, when presented with clear information and
 corresponding pros/cons, will be able to make the choice that is right for
 them and their sites.

 So at least if it's off by default and has a toggle, we can say "Hey,
 there's this new feature, it's has these benefits, but just be aware of
 XYZ potential downsides" then they can choose to turn it on and try it.

 I am still certain that there will be a significant number of problems
 down the right (most acutely due to future thumbnail regeneration) -- and,
 as currently proposed, it will be particularly bad because site owners
 won't have a clue as to why their site's disk usage has skyrocketed
 sometime in the future.

 > The other idea, default to "off", makes this useless imho. Usually 95%
 of options are never changed from their default values. This is a new
 feature that would enhance millions of web sites and bring this part of
 the WordPress image handling to 2022. Why would it be potentially enabled
 on only 5% of sites? Makes no sense to add to core at all in that case.

 You're right: This shouldn't be in core!

 But we're really going in circles here because there's a fundamental
 problem with how WordPress deals with thumbnail images. Until that's fixed
 with some kind of "on first use" system (therefore reducing a huge amount
 of unused thumbnails), any changes to how core deals with
 images/thumbnails is just going to exacerbate the issue.

 So how about putting this on pause, and instead creating a "Media Team"
 tasked with overhauling the fundamental issues with thumbnails?  WebP
 thumbs could then be incorporated properly (and any future formats could
 as well). This would be a MASSIVE WIN for WordPress!

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