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

 Heya all,

 Just jumping in and adding my two cents here. I hear everyone's concern
 and ultimately there are some tradeoffs in every path we could take. With
 that in mind, we could get lost discussing the tradesoffs for
 days/weeks/months without moving forward. We are surely ''not'' going to
 find a solution that suits ''everyone'', but should find one that suits
 the majority.

 I will share my perspective on the things discussed in this ticket:
 - **Not generating both JPEG and WebP version for image sizes:** +1,
 @azaozz (and others) raised some valid concerns and it makes sense not to
 do so
 - **Removing mime types infrastructure:** -1, @adamsilverstein shared the
 benefits of the infrastructure which I agree with. To me it is an elegant
 architecture to support WebP but more importantly for future enhancements.
 With that said, it seems like a reasonable outcome to remove it for now if
 folks feel strongly about it.
 - **Having an opt-in/out UI:** -1000, this is a total no go from my
 perspective. This makes this feature useless, puts the burden on the user,
 bloats the admin UI, prevents WordPress as a platform to move forward (by
 the way, many other CMSes already have WebP by default which proved to be
 successful) and frankly only cater for some use cases which some folks may
 feel strongly about but is not applicable to the vast majority.


 > 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.
 Strong +1, for all the reason I mentioned above (at the risk of sounding
 like a broken record). It also feels to me that this was already discussed
 and agreed upon by the majority and by core committers/leads not to
 introduce a UI option.

 ''Some general though regarding the importance of this feature: WordPress
 as a platform has to move forward, "don't touch it if it is not broken"
 motto is a failure state which prevents evolution and leads to stagnation.
 This may be ok in some cases, but not for a platform which powers a big
 chunk of the web, failing to do so puts the entire ecosystem at risk.
 Evaluated tradeoffs are ok and inevitable.''

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