Your links work OK, though further down the page you have to pass right over them in the toolset area and then click. It’s not even obvious they are links.
1 Like
Seems not even the hovers and bigger middle section works on that version!
By design this should be a “featured” middle section that kind of overlaps the other to left and right sections and has a reddish background by default… hah. Weird!
And thanks again! Helps a lot 
Just let me know if you want something tested.
1 Like
For WordPress users who don’t mind adding a plugin, I can recommend WebP Express plugin
It does these conversion and more importantly it does the part of conditionally loading webP or png (or else) depending on the agent.
The same plugin inspired me to just use picture element like shown in this article Using WebP Images | CSS-Tricks - CSS-Tricks
As I was able to confirm thanks to kind testing of @Flashman, this seems to work just fine
Still, a core implementation in blocs would not hurt at all.
3 Likes
Going further on this I tried WebP JavaScript library which is mentioned in The State of WebP Browser Support - KeyCDN Support however that script has at least one big disadvantage:
It uses base64 encoding for images. This may be OK for small amount of images but with lots of images, the HTML will grow exponentially.
Also, the script is abandoned (not updated since 2018) and didn’t do the job on my tests at all. So, discarded
There is another option mentioned in the cloud which is to use a server side generating WebP on the fly basically, if and only when a browser supports it. The image is then stored and cane be of course reused, together with a servers side rewrite rule. But that is not really what we should be doing, because it means to keep uploading jpegs or pngs, instead of directly using webP
So far it seems the HTML approach is the best way to go… will feedback here if I find other ways of doing this with less code-rewrite.
That was also mentioned in the original discussion. Seems like @norm could Bloc-ify something. 
1 Like
Ideally you want something that works across the app, so not just individual images but also in carousels and backgrounds for example.
While on this subject, I wondered if it might be useful for different formats to have some kind of ID attached, such as one colour for Jpgs and another for WebP so they are easier to organise in the asset manager. Two images side by side, but you instantly know which is the WebP or Jpg. Maybe a single letter W or J in the corner would be less messy.
2 Likes
Playing with the Modernizr I have tested the below which also works fine. It still needs you to save both image types thou. But avoids editing the HTML element to a picture. Useful for backgrounds, for example.
- Build a modernizr package just for WebP with this tool. this will generate something like the below JS which you have to either add directly to
heador enqueue inhead:
!function(e,n,A){function o(e){var n=u.className,A=Modernizr._config.classPrefix||"";if(c&&(n=n.baseVal),Modernizr._config.enableJSClass){var o=new RegExp("(^|\\s)"+A+"no-js(\\s|$)");n=n.replace(o,"$1"+A+"js$2")}Modernizr._config.enableClasses&&(n+=" "+A+e.join(" "+A),c?u.className.baseVal=n:u.className=n)}function t(e,n){return typeof e===n}function a(){var e,n,A,o,a,i,l;for(var f in r)if(r.hasOwnProperty(f)){if(e=[],n=r[f],n.name&&(e.push(n.name.toLowerCase()),n.options&&n.options.aliases&&n.options.aliases.length))for(A=0;A<n.options.aliases.length;A++)e.push(n.options.aliases[A].toLowerCase());for(o=t(n.fn,"function")?n.fn():n.fn,a=0;a<e.length;a++)i=e[a],l=i.split("."),1===l.length?Modernizr[l[0]]=o:(!Modernizr[l[0]]||Modernizr[l[0]]instanceof Boolean||(Modernizr[l[0]]=new Boolean(Modernizr[l[0]])),Modernizr[l[0]][l[1]]=o),s.push((o?"":"no-")+l.join("-"))}}function i(e,n){if("object"==typeof e)for(var A in e)f(e,A)&&i(A,e[A]);else{e=e.toLowerCase();var t=e.split("."),a=Modernizr[t[0]];if(2==t.length&&(a=a[t[1]]),"undefined"!=typeof a)return Modernizr;n="function"==typeof n?n():n,1==t.length?Modernizr[t[0]]=n:(!Modernizr[t[0]]||Modernizr[t[0]]instanceof Boolean||(Modernizr[t[0]]=new Boolean(Modernizr[t[0]])),Modernizr[t[0]][t[1]]=n),o([(n&&0!=n?"":"no-")+t.join("-")]),Modernizr._trigger(e,n)}return Modernizr}var s=[],r=[],l={_version:"3.6.0",_config:{classPrefix:"",enableClasses:!0,enableJSClass:!0,usePrefixes:!0},_q:[],on:function(e,n){var A=this;setTimeout(function(){n(A[e])},0)},addTest:function(e,n,A){r.push({name:e,fn:n,options:A})},addAsyncTest:function(e){r.push({name:null,fn:e})}},Modernizr=function(){};Modernizr.prototype=l,Modernizr=new Modernizr;var f,u=n.documentElement,c="svg"===u.nodeName.toLowerCase();!function(){var e={}.hasOwnProperty;f=t(e,"undefined")||t(e.call,"undefined")?function(e,n){return n in e&&t(e.constructor.prototype[n],"undefined")}:function(n,A){return e.call(n,A)}}(),l._l={},l.on=function(e,n){this._l[e]||(this._l[e]=[]),this._l[e].push(n),Modernizr.hasOwnProperty(e)&&setTimeout(function(){Modernizr._trigger(e,Modernizr[e])},0)},l._trigger=function(e,n){if(this._l[e]){var A=this._l[e];setTimeout(function(){var e,o;for(e=0;e<A.length;e++)(o=A[e])(n)},0),delete this._l[e]}},Modernizr._q.push(function(){l.addTest=i}),Modernizr.addAsyncTest(function(){function e(e,n,A){function o(n){var o=n&&"load"===n.type?1==t.width:!1,a="webp"===e;i(e,a&&o?new Boolean(o):o),A&&A(n)}var t=new Image;t.onerror=o,t.onload=o,t.src=n}var n=[{uri:"data:image/webp;base64,UklGRiQAAABXRUJQVlA4IBgAAAAwAQCdASoBAAEAAwA0JaQAA3AA/vuUAAA=",name:"webp"},{uri:"data:image/webp;base64,UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAABBxAR/Q9ERP8DAABWUDggGAAAADABAJ0BKgEAAQADADQlpAADcAD++/1QAA==",name:"webp.alpha"},{uri:"data:image/webp;base64,UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA",name:"webp.animation"},{uri:"data:image/webp;base64,UklGRh4AAABXRUJQVlA4TBEAAAAvAAAAAAfQ//73v/+BiOh/AAA=",name:"webp.lossless"}],A=n.shift();e(A.name,A.uri,function(A){if(A&&"load"===A.type)for(var o=0;o<n.length;o++)e(n[o].name,n[o].uri)})}),a(),o(s),delete l.addTest,delete l.addAsyncTest;for(var p=0;p<Modernizr._q.length;p++)Modernizr._q[p]();e.Modernizr=Modernizr}(window,document);
- Listen to the classes
no-webpandwebpthat the above JS adds to yourhtmlelement in your CSS like so
.no-webp .etc-sub-class {
background-image: url("./img/oldschool.png");
}
.webp .etc-sub-class {
background-image: url("./img/newschool.webp");
}
This successfully loads .webp or .png depending on support.
5 Likes
So that tells me that I will continue to use jpg and png for the time being. I don’t want to hassle around and add additional stuff just to get them to work on older browsers, and in the end again, not having a significant advantage in terms of loading times. 
From examples I’ve seen conversion from PNG to WebP gives the most significant improvement. JPG is improved and smaller but not to the same extent.
1 Like
That would depend to a largely on how the PNG files were saved. They can be made significantly smaller if you run them through https://tinypng.com. The primary problem with jpg is that it doesn’t support transparency if you need that.
From the tests I’ve been doing the differences between Jpg saved for web vs WebP is pretty enormous and while this may not be a big deal with one or two small images it really adds up on websites that are graphic intensive.
WebP was invented by Google specifically to make smaller better looking images for websites, so I can imagine them being increasingly less tolerant of sites that only offer Png or Jpg, especially when there are several images. WebP is significantly more flexible and suited to the internet.
Sometimes I see people of the forum getting upset about an extra 20kb of code with Bootstrap or some tiny thing that could improve their Google Page Speed score by 5 points, where in practice it is almost entirely inconsequential. In this case, switching from Jpg to WebP we are likely cutting the page size in half with a single step.
The official stats claim around 25% size saving compare to Jpg, which is probably a conservative estimate, but I am seeing more than that in the images I have tried. This also shows the limits of running an old OS for development if it cuts you out of options like this.
I would really like to use WebP, but if I have to put in (for now) more effort (fallback, etc.) to use this image format, then I’m not interested. I just want to swap (replace) JPG/ PNG and WebP should work across the board. But unfortunately it doesn’t. It’s not that tragic for me either, since I mostly design smaller web-projects (with fewer pictures as a result).
It’s an afterthought, but if that Wikipedia article is accurate 93% of browsers already support WebP, however it does not address browsers being used on older OS versions and I would like to see some reliable data on that.
Bootstrap 5 will not support Internet Explorer browsers and I think we might soon be reaching the point where developers should just ignore users of older Mac operating systems. That crunch point might arrive as early as the next Mac OS release in September.
Once people start seeing messages pop up saying they need a modem modern OS it will act as a push to upgrade. Ironically that may even be why Apple has finally adopted WebP. They could have done this years ago.
Do we simply need a bric that tells visitors to use another browser if Safari is found on older OS versions? That way we could theoretically just go with WebP.
1 Like
The easiest way to serve “WebP” AND have fallback for old browsers is to offload your images to a CDN image service like “Cloudinary” or “Shortpixel” I have used Cloudinary on quite a few websites, and the free plan is more than enough for most small “brochure websites”.
Just load your images up to Cloudinary, and use the link to embed them into your website. Cloudinary will identify when an image URL was requested by a browser that supports WebP. In such a case, Cloudinary will automatically convert your image, on-the-fly, to the WebP file format and deliver it cached and optimized. And if the browser doesn’t support WebP, it automatically uses the jpg/png fallback.
The added benefit of offloading images this way, is better loading speed for your websites as well. One of the other added benefits, by having your clients load their images into Cloudinary instead of into the website itself, it will automatically force optimized images! No more 10mb client image uploads to the website!
2 Likes
You have mentioned Cloudinary in the past and obviously like them. It was something I looked at quickly but never signed up, so I have no practical experience there. I take it you can bulk add remote assets to the asset manager in Blocs?
I did something similar in the past with CloudFlare that produced WebP images, while retaining the original Jpgs as a fallback, however this was only available on their paid pro package that worked out at a $20 per site a month, which would be a tough sell to my clients in that instance.
One concern I have about using external services is that it is always potentially another point of failure and complicates matters when troubleshooting is involved, but it’s definitely worth consideration.
For those using a CMS, Volt will resize Jpgs as they are uploaded if you set a maximum size, so this gets around the 10mb uploads, however it does not at present do so with WebP and I believe Jannis is looking at possible options.
1 Like
Hi everyone,
Interesting discussion on webp. I would say that webp is really meant to be a ‘replacement’ for png files (ie transparent backgrounds). I did a little test on a really large image 4K image & set the compression ratios to the same between an online webp compressor and ImageOptim, so it’s comparing apples to apples. When compressing from png to png - got 79% file reduction. When compressing from png to webp - got 91% file compression.
The lesson here is: ~10% better for webp. For normal sized images, that small improvement won’t make much of a difference, unless you have 100’s of images on each page 
And of course, if your clients are still on a Mac (pre-Big Sur) then it still won’t work.
Just my 2 cents on the subject - everyone have a good weekend.
Bill
@Bill That is curious you found relatively little difference and if it was indeed only 10% compared to Jpg I wouldn’t lose any sleep over it frankly, but in the tests I have run it has generally been over 50% lighter with WebP, so on a web page with a gallery selection for example that is a big difference.
Just a follow up thought on this point, but Chrome and Firefox have both adopted AVIF and apparently it was added to the nightly versions of Safari about 6 weeks ago, so it could be here fairly soon.
AVIF is lighter than either Jpg or WebP and it looks like the adoption will be a lot faster, so it stands a better chance of being the default option. We are still left with the question of legacy Mac OS versions with Safari, but a year or so from now we may have a very different situation in terms of web development.
3 Likes
Had heard similar on another forum, that WebP was 10 years old and only just getting wider spread support but with AVIF on the near horizon WebP may just be a temporary stepping stone.
WebP would no doubt have gained more rapid adoption if Apple had decided to support it many years ago and I suspect this was more about corporate politics than anything else. There is some more insight here on AVIF.
https://blog.cloudflare.com/generate-avif-images-with-image-resizing/