[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-patch has-unit-tests needs-dev-  |     Focuses:
  note needs-docs needs-user-docs commit         |  performance
-------------------------------------------------+-------------------------

Comment (by jb510):

 Replying to [comment:66 mikeschroder]:
 [...]
 > I also had the concern about WebP being larger in some cases (which was
 confirmed during image quality testing), and dropping the images that are
 larger solves this concerns.
 >
 > It's worth noting that when WebP is smaller, which in my testing so far
 is common for smaller resolutions even when the largest sizes are bigger,
 the savings percentage-wise are quite significant.

 This seems a little short-sighted to me.  While I agree that we should
 serve the format with the smallest file size by default, it seems to me
 like the generated WebP, even if larger, ought to be retained for future
 use regardless of file size.

 I really don't want a library that looks like
 image-original.jpeg
 image-1000x1000.jpeg
 image-1000x1000.webp
 image-900x900.webp
 image-800x800.jpeg
 image-700x700.jpeg
 image-700x700.webp
 image-600x600.jpeg

 Where only some themnuals have sidecar webp files.  Predictability is
 important because of how the media library works.

 I for one look forward to deleting every jpeg on my site someday in the
 future, and wouldn't want holes where webp's weren't saved. I could care
 less if 1% of the files ended up being served in a format that was 5%
 bigger, It'd rather have the consistency to work with when managing them
 in bulk.

 And again - this all should be opt-in on existing installs for at LEAST
 several versions of WP.

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