Webp support

[jacmaes]

This is a repost from the wishlist & roadmap section of the forums:

One of PW 3.010's major novelty was the introduction of Horst's new image resizing engine that uses ImageMagick. Now I understand that ImageMagick can convert images to Webp, the image format that Google says can reduce image size up to 34% compared to JPEG.

Mozilla is adding support to Firefox, and even the Safari team is playing with it, so it looks like Webp is soon going to be available in most major browsers. If Horst's module can be extended to add Webp conversion, that would be a great addition to PW's already very powerful image manipulation arsenal.

I'm currently using the free ImageEngine Lite to serve Webp images to supporting browsers, and the results are impressive. I routinely get images that are between 25 and 60% smaller compared to JPEG, with the same visual quality. I would love to eliminate the need to rely on a third-party service though.

[LostKobrakai]

I think such functionality doesn't belong into the core, but rather into a module. Firstly it's not granted that ImageMagick is available on servers (shared ones might not supply it) and – as you said – by now support is planed for other browser besides Chrome, but not there yet.

[ryancramerdesign]

Webp does sound pretty exciting. Certainly if Chrome gets support for it, that would be the trigger that we should support it too. Though it's probably too early to be a core feature (certainly less than 30% would use it at present), but it's good to have on the map. Since @horst-n is the author of the module that would be applicable, I've tagged him here in case he wants to start looking into it for the future. Thanks.

[LostKobrakai]

Chrome does support it natively, but all other browsers are only catching up on support :D

[ryancramerdesign]

Sorry I misread that then. If Mozilla and Safari are also playing with it, then lets see what @horst-n thinks. 25-60% smaller sizes are pretty darn compelling. Maybe still belongs in 3rd party module, but if it's something that can be supported relatively easily by our existing ImageMagick module, why not. On the other hand, if it requires bringing in some other image manipulation library, then I'd say it probably is better as a 3rd party module.

[jacmaes]

Thanks guys for your input. My idea was indeed to extend the ImageMagick module as it seems the most straightforward thing to do right now, and as @LostKobrakai points out, we cannot assume that ImageMagick is always installed. Maybe I shouldn't have posted it here then as it's not strictly a request for an addition to the core. Sorry about that.

I have a question about the 30% rule you mention for inclusion into the core. It seems reasonable to me, but how do you actually measure it? Through likes in a forum thread and/or a github issue? Wouldn't something like UserVoice (it's so expensive, though) work much better? MS Edge and Digital Ocean use it to gather community feedback and prioritize. What do you think?

[ryancramerdesign]

The 30% thing isn't really a rule, just a ballpark way to look at adding
new things. There's plenty of stuff in the core that doesn't fit that too.
Once something is added, it's hard to take away, so that's where the 30%
thing is ballpark just purely for thinking about it. For the webp thing,
I'd probably look at it like "how many people are likely to be using it in
a few years." With what you've stated, and Chrome supporting it, plus
Firefox and Safari likely, it seems like a lot of us might be using this
quite soon. The ImageMagick module is made by @horst-n, but it's also a
core module. If Horst is interested in adding support for it sometime soon,
I see no reason not to.

On Fri, Sep 23, 2016 at 1:42 PM, Jacques Maes notifications@github.com
wrote:

Thanks guys for your input. My idea was indeed to extend the ImageMagick
module as it seems the most straightforward thing to do right now, and as
@LostKobrakai https://github.com/LostKobrakai points out, we cannot
assume that ImageMagick is always installed. Maybe I shouldn't have posted
it here then as it's not strictly a request for an addition to the core.
Sorry about that.

I have a question about the 30% rule you mention for inclusion into the
core. It seems reasonable to me, but how do you actually measure it?
Through likes in a forum thread and/or a github issue? Wouldn't something
like UserVoice (it's so expensive, though) work much better? MS Edge
https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer and Digital
Ocean https://digitalocean.uservoice.com/forums/136585-digitalocean use
it to gather community feedback and prioritize. What do you think?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUCUHbvh3HLQMOutnYNXy3i7seVPNVPks5qtA-NgaJpZM4KEOpa
.

[jmartsch]

We need WebP support in the core as it only has advantages (and one disadvantage): Edge (yes, Edge) supports it, as well as Chrome, the Android Browser (since 4.2) and Opera. Firefox 65 which will be released in January 2019 will implement it very soon and the Safari team is also experimenting with it.
Actual support table here: https://caniuse.com/#feat=webp

The disadvantage is, that images that are being downloaded can not be opened with standard OS applications, but with tools like IrfanView or XnView you can also view WebP files. This makes it also hard to share these images and is why Facebook removed WebP from their service, as people tend to download and share the images. But I think thats not the case for most websites. And also it is a decision of the developer, if he uses WebP or another image format. So we have no drawbacks if this would be in the core (or a module, but I don't see why it should be a module).

[horst-n]

@ryancramerdesign It seems to be really useful to have at least a basic support for webp outputformat.
I think we should add an additional options param like "convertto" or "convert", that expects one param out of ["webp", "jpg", "png", "gif"], (maybe with a default to "webp"?). This way we can change any source format to any output format. We will not support webp as inputformat, (at least not in the first step).

We would need a core change for "webp" output alone, but it will be no overhead to include all fileformats as output. This way we will add optional webp output format and conversion for the other legacy fileformats.

What do you think, Ryan? I'm able to write the needed code changes and sent a pull request to the dev branch.

[jmartsch]

Please do not set webp as a standard setting for now, because we have to take into account, that not all browsers support it at the moment. I would leave the standard as it is, and let the dev decide which format to use.

It would be nice if you can generate the webp file additionally to the standard image format via the API.
This is because right now we have to serve webp to supported browsers, and a fallback format (JPG, PNG, GIF) for browsers that dont support it.
The easiest way to do it right now is when using a picture element with different sources:

<picture>
  <source srcset="img/awesomeWebPImage.webp" type="image/webp">
  <source srcset="img/creakyOldJPEG.jpg" type="image/jpeg"> 
  <img src="img/creakyOldJPEG.jpg" alt="Alt Text!">
</picture>

If we had an API command like $image->format('webp') a developer has the freedom to choose which images are outputted as jpg, png or webp (regardless of the standard setting).
So we could keep the default image format that is defined in the settings when using $image->url.
And we could generate a webp image with $image->format('webp', $webpoptionsarray)->url.
So the sample picture code above could read:

<picture>
  <source srcset="{$image->format('webp')->url}" type="image/webp">
  <source srcset="{$image->url}" type="image/jpeg"> 
  <img src="{$image->url}" alt="Alt Text!">
</picture>

Because the quality setting of a webp image can be much lower than that of a jpg, with almost same results, it would be good if we had this API function .
Something like this:

$options = array(
  'quality' => 70,
  'format' => 'webp'
);
$img = $image->size($x, $y, $options); 

What do you think about this?

[horst-n]

There is no standard settings at all. We do not change any thing on the behaviour of image rendering. What I meant is that we only add a new functionality via options param.
If we call it "convert", what I suggested, we a) have to add one of the outputformat filename extensions, or b) simply boolean true or "1", as a shortcut to "webp". This was thought as a convenience only to the new options param, like we have a lot of this in PW. Why would it be useful to have a shortcut only for webp? Because a conversion to webp seems to be the main reason for reading images of different source formats and convert into another (output)format.

Until now, we have not had a conversion feature at all. The webp discussion first brought this in. To enable conversion support for the legacy image formats is only a side effect that can added with nearly no extra costs. :) We only will add a basic support for different output formats, (with webp as default param shortcut or not), like your above example with the options array, where you called the new param "format", what I called "convert". Which param name is the most useful is open for discussion. The most descriptive seems to be "outputformat", but is to long in my opinion.

[jmartsch]

I opt in for naming the setting "outputformat". I do not think, that the length is an issue.
Also it would be better to explictly name the extension, instead of a boolean, just because it speaks for itself, rather than guessing what "1" means.

[horst-n]

Ok, then we have: $options = ["outputformat" => "webp"] (or "jpg" | "png" | "gif")

[teppokoivula]

Is there a risk of confusion, i.e. do we have other formats to define as well? If not, then I'd go with "format". I don't see length as a real issue here, but being concise is usually better than.. well, the opposite :)

[MrSnoozles]

I think this should be a core feature for at least one of the following reasons:

• faster page load times are always good, even better when they come automatically
• PageSpeed Insights is now complaining if images are not provided in next-gen formats (essentially meaning WebP)
• browser support is already at more than 70% according to https://caniuse.com/#search=webp

A Wordpress module that does a good Job at providing WebP support is: https://wordpress.org/plugins/webp-express/
It creates an .htaccess entry, that redirects images to a script that generates the webp version. But only if the browser supports webp.

The .htaccess entry looks like this:

# BEGIN WebP Express
<IfModule mod_rewrite.c>
  RewriteEngine On

  # Redirect to existing converted image in cache-dir (if browser supports webp)
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME} -f
  RewriteCond %{DOCUMENT_ROOT}/wp-content/webp-express/webp-images/doc-root/wp-content/$1.$2.webp -f
  RewriteRule ^\/?(.*)\.(jpe?g)$ /wp-content/webp-express/webp-images/doc-root/wp-content/$1.$2.webp [NC,T=image/webp,QSD,E=EXISTING:1,L]

  # Pass REQUEST_FILENAME to PHP by in request header
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME} -f
  RewriteRule ^(.*)\.(jpe?g)$ - [E=REQFN:%{REQUEST_FILENAME}]
  <IfModule mod_headers.c>
    RequestHeader set REQFN "%{REQFN}e" env=REQFN
  </IfModule>

  # Redirect images to webp-on-demand.php (if browser supports webp)
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME} -f
  RewriteCond %{QUERY_STRING} (.*)
  RewriteRule ^(.*)\.(jpe?g)$ /wp-content/plugins/webp-express/wod/webp-on-demand.php?wp-content=wp-content&%1 [NC,L]

  <IfModule mod_headers.c>
    <IfModule mod_setenvif.c>
      # Set Vary:Accept header for the image types handled by WebP Express.
      # The purpose is to make CDN aware that the response varies with the Accept header, so it should not just use the URL as cache key, but also the Accept header. 
      SetEnvIf Request_URI "\.(jpe?g)" ADDVARY
      Header append "Vary" "Accept" env=ADDVARY

      # Set X-WebP-Express header for diagnose purposes
      # Apache appends "REDIRECT_" in front of the environment variables defined in mod_rewrite, but LiteSpeed does not.
      # So, the next line is for Apache, in order to set environment variables without "REDIRECT_"
      SetEnvIf REDIRECT_EXISTING 1 EXISTING=1
      Header set "X-WebP-Express" "Redirected directly to existing webp" env=EXISTING
    </IfModule>
  </IfModule>

</IfModule>
<IfModule mod_mime.c>
  AddType image/webp .webp
</IfModule>

# END WebP Express

[TomS-]

I feel like in 2019, this is becoming more and more important. I think if this isn't a feature soon it will start turning people away from ProcessWire.

[horst-n]

see: processwire/processwire#141

[jacmaes]

WEBp support has been added in ProcessWire 3.0.132, so I'm closing the issue.