In case your server doesn’t allow Webp Express to auto generate webp images, or for any other reason, you might want to bulk convert images in webp.

On windows the best solution I found was to use https://www.imagemagick.org/script/convert.php

I needed to add some batch scripting to allow for bulk conversion 

I tested this code with the inconvenience that the file name retains .jpg and get appended with the webp extension, which is not suitable for my case use. I corrected that with a python script that I had ready at hand for batch renaming files. Here is the batch script:

cd C:\Users\Admin\Documents\webptest\2018\09
dir /B /A-D > list.txt
FOR /F “tokens=* delims=” %%x in (list.txt) DO magick convert %%x %%x.webp

While looking for a solution to remove the file extension, I found this nice code from stackoverflow that I modified to suit my needs:

@echo off
for /R “C:\Users\Admin\Documents\webptest\2018\10” %%f in (*.jpg) do (
magick convert %%f %%~nf.webp
)
pause

Tested and working. The file are saved in the directory containing the batch script.

Google page speed insights encourage you to use next-gen image formats.

One question that should arise immediately is the one of compatibility. Google has already tried to push its highly efficient image format webp since launch in 2010 the 30th of September,   but without compatibility by competiting browsers such as safari, firefox or internet explorer and edge,  webmaster did not adopt it as it required browser detection to serve the proper image format to the corresponding browser or load a javascript file to insure compatibility.

Nowadays it is not one but three so-called “next-gen” format that are available on the market, each compatible with a single major browser. Although things are about to change for webp.

JPEG 2000: Safari and Safari Mobile, Chrome Mobile, Facebook on IOS, Google search app. about 14% market share all device included.

JPEG XR: internet explorer and edge

WebP: Chrome, Edge and Firefox 65 in 2019.  with

As we can see the compatibility range for webp has increased although Apple format JPEG 2000 is perfectly at ease in mobile environment but represent only 14% market share globally.

source:

https://www.scientiamobile.com/jpeg-2000-jpeg-xr-support-browser/

https://www.zdnet.com/article/firefox-and-edge-add-support-for-googles-webp-image-format/

http://gs.statcounter.com/

 

Now that we have some information on the different picture formats market share, we need a  way to share the right image to the correct browser. You can achieve this by using srcset

“Use srcset to select each file type. Srcset is an image property that lets you toggle between images based on various criteria, such as high-resolution displays which are typically only seen on newer laptops and mobile phones.”

https://shubox.io/blog/2018/05/10/choosing-the-right-next-gen-format-for-your-images/

We could ponder on the inability of the industry to make changes and agree on the adoption of a new single format required by the exponential rise of data transiting in our network and the corresponding needs of space in servers for caching and indexing those data, but I’d like to reflect on the opportunity to adopt not one but two or three of those format.

The strategy would be to take the advantage of lazy load to take the time to get the device browser and fetch the proper image version only when required, those keeping the page load time low.

To get the screen resolution with javascript:

window.screen.width *window.devicePixelRatio  window.screen.height * window.devicePixelRatio

Source: https://stackoverflow.com/questions/2242086/how-to-detect-the-screen-resolution-with-javascript

Knowing the screen resolution, we can then serve the best suited pictures.

Actually a better way to serve different picture depending on screen resolution would be to use srcset introduce with hml5:

<img alt="my awesome image"
  src="banner.jpeg"
  srcset="banner-HD.jpeg 2x, banner-phone.jpeg 640w, banner-phone-HD.jpeg 640w 2x">

“The above would serve banner-phone.jpeg to devices with viewport width under 640px, banner-phone-HD.jpeg to small screen high DPI devices, banner-HD.jpeg to high DPI devices with screens greater than 640px, and banner.jpeg to everything else.”

srouce: https://www.html5rocks.com/en/mobile/high-dpi/

The syntax I currently used is the following:

<picture>
  <source media="(min-width: 650px)" srcset="img_pink_flowers.jpg">
  <source media="(min-width: 465px)" srcset="img_white_flower.jpg">
  <img src="img_orange_flowers.jpg" alt="Flowers" style="width:auto;">
</picture>

The advantage here is to be able to use the media attribute and instead of the width use the screen resolution in dpi:

resolution

Specifies the pixel density (dpi or dpcm) of the target display/paper. “min-” and “max-” prefixes can be used. Example: media=”print and (resolution:300dpi)”

And the good news is that it works with amp-img elements too:

<amp-img alt="Hummingbird"
  src="images/hummingbird-wide.jpg"
  width="640"
  height="457"
  layout="responsive"
  srcset="images/hummingbird-wide.jpg 640w,
            images/hummingbird-narrow.jpg 320w">
</amp-img>

Source: https://www.ampproject.org/docs/design/responsive/art_direction

last but not least it seems to work out of the box for webp with src picture as fallback:

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

according to: https://css-tricks.com/using-webp-images/

why it works : https://developers.google.com/speed/webp/faq

HTML5 <picture> element

HTML5 supports a <picture> element, which allows you to list multiple, alternative image targets in priority order, such that a client will request the first candidate image that it can display properly. See this discussion on HTML5 Rocks. The <picture> element is supported by more browsers all the time.

source:

For high dpi screens, you will get the best results by serving pictures that are twice their size on screen and heavily compressed with image quality down to 20. The picture will look crispier on high dpi display than the uncompressed picture served full-size. The loss of quality on standard display will be minimal so you can even go with generalizing the process for all platform. The advantage on top of the crispiness on high-dpi is that the picture is actually lighter than the original.

But even more important in our case, we want to know what image format the browser supports.

As I plan to use implement amp, I looked at info about device detection and amp, and this stackoverflow pop-up and was quite satisfying:

https://stackoverflow.com/questions/37103814/how-does-the-server-know-when-to-serve-an-amp-page

Here is an async example code for webp:

async function supportsWebp() {
  if (!self.createImageBitmap) return false;
  
  const webpData = 'data:image/webp;base64,UklGRh4AAABXRUJQVlA4TBEAAAAvAAAAAAfQ//73v/+BiOh/AAA=';
  const blob = await fetch(webpData).then(r => r.blob());
  return createImageBitmap(blob).then(() => true, () => false);
}

(async () => {
  if(await supportsWebp()) {
    console.log('does support');
  }
  else {
    console.log('does not support');
  }
})();

source: https://davidwalsh.name/detect-webp

a similar example is given in the google webp source given above.

Last thing to see will be the use of CSS sprite and we will have a complete overview on the question.