WebP and the Safari question

General Discussion
1

Nearly all the major browsers have compatibility with WebP images, which offers similar or better quality than Jpg at significantly smaller file sizes that will facilitate faster page loading. Given some upcoming changes with Google in May that could become especially important.

In one test I ran, a large image file saved for web as Jpg was reduced from 903kb to just 357kb as WebP and I have little doubt that could have been squeezed further without loss of visual quality.

The big nuisance here has always been Safari, because Apple were ridiculously slow to embrace this format and it only became a reality with Safari 14 under Big Sur.

In a couple years time I think this will be a non issue and Jpg will effectively become a legacy format for web usage, but right now it feels like we are sacrificing a lot in terms of page weight by only adding Jpg images in most cases.

I am looking for ways to adopt WebP now without losing too many users stuck on older versions of Safari and Mac OS. When I tested this earlier, WebP was added to the asset manager in Blocs and worked perfectly in Safari on my Mac mini running Big Sur, however it appeared like a broken link in Mojave. All other browsers were fine though.

Looking at possible solutions, I know that Cloudflare Pro allowed users to upload Jpg images and they would then serve WebP conversions when possible or fall back to Jpg if necessary. That’s great in theory as a server side solution, however it was costing $20 a month per site the last time I checked a couple years back.

I know there is a stack available for Rapidweaver users called WEBPSTACK that allows you add images, specifying the WebP and Jpg separately, so the right one is served in each case. Something like that in Blocs sounds like a reasonable option for an image bric.

There is actually a useful free app for converting files from Jpg to WebP on the App Store.

https://apps.apple.com/gb/app/webponize/id1526039365?mt=12

There was an article on this site below offering a couple potential solutions that could be worth investigating as well.

The ideas they suggest would allow the uploading of WebP alone, however Safari would still show the images correctly, as long as WebM is permitted in the browser. The two script options were Weppy and WebPJS. It would have to be investigated to see in practice how this worked and if there were any performance penalties, but in theory it would greatly simplify matters.

2 Likes
2

A possible solution (also from the Rapidweaver world) was to use the retina image “conventions”. For the 1x image use a .jpg file as fallback and use WebP as the 2x image.

Don’t know if this would work with Blocs though if it accepts WebP images for this?

3

We already have built in options with Blocs for x1, x2 and x3 in the side panel, however these do not currently specify WebP or Jpg. I imagine Blocs is currently treating them the same in that regard.

4

Yes I saw the support article for 1-3x, if they are just containers it might well work?

Only on Blocs 3, not had a chance to do any actual testing yet.

5

Those do not differentiate between formats. In fact you could put the x3 image in the x1 slot and vice versa, so Blocs would just serve what was selected according to the device’s screen resolution. That wouldn’t be sufficient in this instance to enable WebP or Jpg depending on the browser, though the general concept would be fairly neat in theory if it could be adapted.

6

A week ago I converted all images on my sites to webp
I’d never have thought of something like „older browsers“!

This is bad, specially given the speed improvements that it would bring…
perhaps time to add a pop up „update your system“ to my sites lol.
I’m definitely not going back to jpeg or png.

Thanks for the heads up however, I can’t do the same „don’t care“ approach on client sites :stuck_out_tongue:

7

I would have ditched Jpg long ago if it hadn’t been for Safari and I think it has been holding us back, but now feels like the right time when we need to be thinking of this.

On one site I am building for example, there are a number of large portfolio images on each page, so with Jpgs they are coming in at around 6mb per page. If you look at this example the image is 523kb as Jpg that has been optimised for web, but just 146kb at WebP, so that’s a 72% saving and I could squeeze harder while still maintaining good quality.

Screenshot 2021-04-21 at 18.46.14
Screenshot 2021-04-21 at 18.46.14953Ă—555 99.2 KB

In a couple years time I think I’ll ignore users of older OS versions and Safari, much like I currently ignore Internet Explorer, but right now WebP only works in Safari if you are using Big Sur and Safari 14, so that is less than a year old. I think we need a solution that gets us through this transition period without giving up the clear advantages of WebP.

Naturally this will only work if you are also using Blocs with Big Sur, so older OS versions are out because WebP is simply not supported in those cases.

1 Like
8

I use SIRV to host and serve all my images, it’s a paid option (one account can serve many websites). Their code deals with all the image sizing, compression to retina jpgs, webp and I believe in the future: avif and chrome data-saver. They also lazy load video files, albeit quite small file sizes compared Vimeo etc.

It’s not the perfect solution and will not suit everyone, but my experience has been really positive, tech support is second to none and they do VAT invoices :slight_smile:

I’ve found on busy websites, the response time to fetch the required image is around 0.04 seconds, it all depends if the image file is already cached on the CDN.

1 Like
9

I’ve just tested my site with Safari developer tools using 13…1.3 safari; The images show great, despite being webP.

So … either the Safari dev tools are bad, or the caniuse.com data is outdated. According the caniuse, only safari 14.x supports it. Weird///

10

@smileBeda What OS are you running? I am guessing it is Big Sur, because it didn’t work on Mojave when I tried earlier with Safari 13.

11

google dev suggests to leverage https://modernizr.com
I haven’t played with that library yet but it seems able to efficiently detect supports, and hence one could dynamically load specific images perhaps also combining this with lazy load. Means, before triggering a lazy load, detect the support and load the specific image…

But I don’t think I’ll go there, at least not for my own site(s). If clients want safari support they will have to stick with conventional. I think adding a library to detect support just kills off the actual idea of serving speedy, lean and lightweight sites… Resizing and using less huge images should do just that, if backward compatibility is a concern.

Sad, thou. Was really excited about this webP :smiley:

12

yes, its as usual latest versions, big sur in this case
But the safari browser has a develop tool to test with different browsers. When I use it, it still shows the images.

So the testing tool is not really simulating the browsers version specified in the settings?
Since you have an older OS + browser, what do you see here? When I test with the safari dev tool set to safari 13.x I still see actual images. However that might be erroneous then…

13

I had to fire up the old beast, but basically your images are missing with Safari 14 on Mojave. I thought it was 13, but turns out it is 14.

Screenshot 2021-04-21 at 19.11.35
Screenshot 2021-04-21 at 19.11.354046Ă—2800 592 KB

I think support for legacy versions of the OS and Safari will really come down to market share and right now it is quite high, not least thanks to the iPhone. It’s also Catalina we need to consider.

1 Like
14

I think you have to treat those with a pinch of salt, just like online emulators for mobile devices. Nothing beats real world testing.

1 Like
15

You’re only able to change there how the browser Client will identify itself (browser agent name). I doubt it will change its rendering engine to switch off functionality.

1 Like
16

But that means it’s actually OS related, because latest safari is the version 14.
Being me on Big Sur, that would be the only difference left.

Well anyway- thanks for the test!
Also good I added some text and alt information hehe. At least people know what it should be lol

Do the links work? Or are those broken since they wrap the actual images?

And I appreciate the time you took for this!!!

17

Lol
Gosh I just see I added the same alt to all 3 images
:man_facepalming:

18

I believe it’s mainly OS related but also requires Safari 14. My guess is that most users of an older OS will update Safari if the option exists, but automatically excluding any Safari user running an OS older than Big Sur is heavy hit.

19

My Seo consultancy rates are very reasonable :rofl:

20

Yeah I may have to reconsider
After all on this front page it’s Just the 3 (corrected… 5 images) images i would have to serve conditionally…

Will see if I can make time for it and test the modernizer option google suggests

Or perhaps I’ll just serve svg. Would probably be wider supported (for these kind of graphics - not for actual images of course)