[wp-trac] [WordPress Trac] #55443: Create WebP sub-sizes and use for output

WordPress Trac noreply at wordpress.org
Thu Jul 14 18:48:35 UTC 2022

#55443: Create WebP sub-sizes and use for output
 Reporter:  adamsilverstein                      |       Owner:
                                                 |  adamsilverstein
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Media                                |     Version:  6.0
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-      |     Focuses:
  testing needs-dev-note needs-docs needs-user-  |  performance
  docs                                           |

Comment (by adamsilverstein):

 Hey @MatthiasReinholz, thanks for the feedback. Responses inline below:

 > So if I understand right, the current approach is to make WebP the
 default image format for all Core image sizes, correct?


 > additional resources for this conversion are tremendous.

 I'm not sure I agree. Resources for generating images when you upload an
 image will increase dramatically, however resources to serve an image will
 be lowered. Since image uploading is very rare compared to image serving,
 the extra effort to compress and store images should be worth it.

 > Every single plugin in the directory utilizing MozJPEG compression plus
 PNG compression (and no WebP conversion) will generate competitive (IMHO
 better) results than the currently planned Core solution. This is because
 the file sizes will be comparable but we don't generate duplicates.

 I'm not sure what you mean by "MozJPEG compression plus PNG compression" -
 isn't PNG a separate format?

 MozJPEG is not widely available on PHP servers whereas WebP is. WebP
 offers additional benefits over MozJPEG  compression/quality wise and also
 offers transparency and a lossless mode so it has the potential to replace
 transparent PNGs for example. Additionally we are building hooks in so
 existing plugins can control and integrate with the core feature.

 > Further, there are other next-gen formats coming up that are even more
 efficient than WebP (e.g. AVIF).

 Absolutely and this feature is built with those potential formats in mind.
 Still, major browsers still don't support AVIF (Safari has announced
 support in their next release, hopefully Edge will follow suit). In
 addition, AVIF support isn't available in PHP until 8.1. Future potential
 improvements aren't a good reason to not take advantage of the significant
 improvements available in WebP now.

 > it will also be a serious threat to plugin authors and existing larger
 websites that do not pay attention to this change

 this is a significant change and I agree large sites and plugin authors
 need to pay attention to these changes to choose the best path forward.
 I'm not sure about the threat to plugins - the team reviewed many
 image/optimization plugins and WebP is typically a very small part of what
 they offer.

 > Therefore, I'm questioning why this functionality should be activated by
 default at this stage. IMHO, it should be opt-in only.

 Appreciate the concern (although I don't completely agree). We are
 starting with the change only for core image sizes in part as a way to be
 cautious about impact and give the ecosystem time to adapt (eg. so plugins
 or themes that add custom sizes can decide if they want secondary mime

 > Plus ideally, we would already start to think about adding further image
 formats to be supported by this feature.

 +1 this is already underway in the Performance Lab plugin where we have
 open tickets exploring AVIF and JPEGXL support, as well as adding the
 `picture` element to enable serving fallback images.

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

More information about the wp-trac mailing list