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

 I agree with the latest two comments, and to me this discussion has
 increasingly become about general sentiment and opinion rather than facts.
 Additionally, I see some arguments being raised again which aren't
 relevant anymore based on the updated direction we've been leaning towards
 most recently. Most of the points here have been discussed for a long time
 already, though I'd like to point out the main new aspect that had not
 been considered prior is the increased resources needed for an upload as
 pointed out by @azaozz and @dd32 just a few weeks ago. As @TweetyThierry
 already mentioned above, there is no decision in this which will satisfy
 everyone, so we will need to make a decision that benefits the vast
 majority (>80%) based on the data we have. So I'd like to compare the
 approaches here, listing the benefits and tradeoffs over "doing nothing"
 for now (thus keeping the status quo).

 **Generating WebP instead of JPEG:**
 ''(while keeping at least the original JPEG around)''

 Benefits:
 * roughly 30% smaller image files (29% if we choose quality 84, 36% if we
 choose quality 82) for ~98% of global users, leading to faster performance
 * reduced filesystem storage needs to ~70% of what it was before
 * similar resource needs on image upload

 Tradeoffs:
 * regression in performance for the remaining ~2% of global users who are
 on old browsers (due to loading a higher resolution JPEG image)

 **Generating WebP in addition to JPEG:**

 Benefits:
 * roughly 30% smaller image files (29% if we choose quality 84, 36% if we
 choose quality 82) for ~98% of global users, leading to faster performance
 * similar experience for the remaining ~2% of global users who are on old
 browsers (as JPEG for every size will be available)

 Tradeoffs:
 * increased resource needs on image upload, leading to timeouts more often
 * increased filesystem storage needs to ~170% of what it was before

 **Based on the above, and also based on much of the recent conversation
 here, it makes most sense for the vast majority to generate WebP instead
 of JPEG.**

 Regarding the multiple MIMES infrastructure: I am undecided on whether to
 keep it or not at this point, though I definitely think in the long term
 it will be beneficial. The main benefit for keeping it now would be that
 it would allow site owners to go with the 2nd approach above, essentially
 giving them a third option in addition to "Only WebP" vs "No WebP". Many
 contributors were also requesting that in earlier discussions of the
 feature, and arguably on a good tier host with solid resources this should
 be possible. With that said though, I also see that it may be safer to not
 ship it until we are more confident there will be no timeouts on upload
 (e.g. by implementing fully asynchronous upload, as suggested above
 already).

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