[wp-trac] [WordPress Trac] #35725: Add WebP support.

WordPress Trac noreply at wordpress.org
Fri Mar 19 17:17:23 UTC 2021


#35725: Add WebP support.
-------------------------------------------------+-------------------------
 Reporter:  markoheijnen                         |       Owner:
                                                 |  adamsilverstein
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  5.8
Component:  Media                                |     Version:  3.5
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-unit-    |     Focuses:
  tests needs-dev-note dev-feedback              |
-------------------------------------------------+-------------------------

Comment (by marylauc):

 Replying to [comment:120 adamsilverstein]:
 > @marylauc thank you for your feedback!
 >
 > > The recommended way to test for webp  support is to use the "accept"
 request header.
 >
 > Good to know this is a reliable approach. I was mainly considering the
 client side solution because page level caching is commonly used in
 WordPress, so all users get served the same (cached) page. Client based
 solutions would still work in these cases, server side would not.

 That's a good point. In that case you need a client side solution indeed.

 #comment:112 points out that "Testing for WebP compatibility (a la
 Modernizr) requires the ability to inject a data-uri image into the DOM.
 Sites with CSP restrictions prohibiting script-generated data: sources
 won't be able to execute the tests". This seems true, and not only that,
 but a shim won't work either on such a host, as it replaces webp image
 with data urls. I don't know how common it is to have such a tight CSP
 policy.

 > >Both imagemagick and GD use the libwebp encoder, so they should give
 very similar results. At most they might be using slightly different
 versions of the library or use different default settings.
 >
 > Good to know!
 >
 > One follow up question on Imagick vs LibGD: When researching animated
 image support (eg. animated gifs/pngs -> WebP), I found this ticket
 indicating webp.animated format is only supported in Imagick, not in GD -
 https://github.com/libgd/libgd/issues/648. Any feedback on this or how to
 detect library animated support?

 Sorry this sounds like a PHP question more than a webp one and I'm not
 familiar with this at all.

 > > The default quality setting (75) is the value we usually recommend for
 webp, but testing on a dataset and choosing a quality value that gives the
 DSSIM you want sounds like a great idea.
 >
 > Thanks for all the testing details. This will help us find the best
 values to match what we have in WordPress already although I don't want to
 redo testing others have already completed. I found this existing research
 - https://developers.google.com/speed/webp/docs/webp_study - are you aware
 of any others?

 This is our latest data, I'm sure there are more unofficial comparisons on
 the web. But this kind of study compares the visual quality (PSNR/SSIM) of
 compressed images for a given bitrate (or conversely compare the size for
 a given visual quality), which tells you which format performs better in
 general, but doesn't tell you which quality setting to use for a desired
 SSIM. cwebp does have a "-psnr" option which allows you to specify a
 target psnr, but it's much slower than just providing a quality setting.

 I think running a small experiment on the same dataset used for the switch
 to quality 81 would make sense to find the right value for you.

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


More information about the wp-trac mailing list