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

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

 Even though there seems to be a filter to opt-out, I don't believe this is
 the most efficient approach.

 As we can see in the discussions on the various posts and comments on this
 topic, WebP always requires the original JPG files to be available as a
 fallback. Hence, we are generating duplicate files (same content, another
 format). This may not be an issue for small websites. But if you are
 managing websites with GB and TB of media, this is a factor. Further, if
 we take into account the global reach of WordPress with smaller websites
 the aggregated additional resources for this conversion are tremendous.

 From a sustainability perspective, duplicate files and unnecessary
 computational load cannot be the desired approach for the **entire
 WordPress ecosystem**.

 One could argue that we'd save resources by transmitting smaller image
 files. My conclusion would still not be to convert to WebP by default but
 to add compression to existing file formats at first.

 Based on various tests and all the comments across these posts here, I
 don't see a vast advantage of WebP over MozJPEG JPGs and compressed PNGs.
 WebP is actually even larger than compressed PNGs in many cases. MozJPEG
 may not be a realistic solution due to the technical implications (see
 https://github.com/WordPress/performance/issues/294).

 Still, I'd imperatively raise the question if WebP conversion should be a
 Core feature (plus activated by default). We already have a vibrant set of
 plugins about image optimization
 (https://wordpress.org/plugins/search/image+optimization/). Many of them
 are already taking care of WebP.

 **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.

 Image optimization is an important topic for page performance. However, we
 will not be able to change JPG and PNG as the default formats for content
 creation (users will upload files in those formats in almost all cases).
 WebP support still (and most likely always will) require a fallback file.
 Further, there are other next-gen formats coming up that are even more
 efficient than WebP (e.g. AVIF).

 I definitely see it as a big advantage to add Core support for additional
 MIME types for sub-sized image files. But I can't see adding conversion to
 a specific other file format as preferred behavior. This may help to
 optimize the market position of WebP but it will also be a serious threat
 to plugin authors and existing larger websites that do not pay attention
 to this change.

 Therefore, I'm questioning why this functionality should be activated by
 default at this stage. **IMHO, it should be opt-in only.** Plus ideally,
 we would already start to think about adding further image formats to be
 supported by this feature.

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