WebP: How to create fallback to JPG?

Hey people

The new WebP converter in Webflow is nice.
But since the format isn’t supported by all browsers I asked myself if there’s a way to create an automated fallback function to JPEG for all unsupported browsers somehow.

I know its kinda tricky because if you convert a JPG image to WebP inside Webflow the original file will be deleted. But you could just upload an image twice and compress one of them so you have them in both formats.

Does someone know how to create a fallback with javascript or something else?

Seems to me you have nothing to worry about, unless you’re concerned with IE 11 visitors.

1 Like

Hey @Franne_Norman thanks for the reply.

What about Safari before September 2020?
As far as I can tell all Safari users that have a OSX version older than Big Sur (which was released in November 2020) can’t see webp images.

Or am I missing something?

Not missing something at all.

People using High Sierra or under aren’t using Safari 14, which is, like you said, the version in 2020 that has Webp support.

So that’s still 8,86% that do not have a webp-supported Safari browser. On the other hand, easily half of those people use Chrome.

Either way, there’s definitely still a reason to look for a fallback to jpg/png depending on the demographic of your website visitors.

Let’s see if anyone else on this forum can shed some light on this.

1 Like

Webflow does not provide auto fallback, but you can do it manually by downloading a copy of your image, converting it to Webp, uploading it back to assets, then using the picture element to handle the presentation with custom code. The other alternative is to use custom code with a product like Cloudinary which can autodetect support and deliver the right image to the user dynamically. Life would be so much easier if Webflow simply supported accessing the SRC attributes of an image like the HTML Specification allows for. Then you could have dynamic image transformations without code blocks and easily use external images like we do on all other platforms. This is the main reason why I will not use Webflow for my Photography sites.

3 Likes

I absolutely agree. Accessing the src attribute would be so nice!

Another thing that would make it much easier is if Webflow would automatically create the webp image WITH a fallback function. I don’t get it why they didn’t do this in the first place.
I just want to be able to choose if I want Webflow to create and provide a webp ON TOP of the jpeg or png version.

I guess I just have to wait until most of Safari users upgraded to at least Big Sur. Until then this feature doesn’t seem to be worth using (especially here in Switzerland where so many people use macs).

@Schuschi_Eyes - I would consider a manual/automatic approach for large images to reduce page weight. I have been doing that for the last couple of years via Cloudinary and imgix CDN’s. Page speed is very important on marketing sites I build.

Hi,

I have just published this post. I’m pissed off, because unfortunately I totally ignored the fallback at the time of the conversion. In the agency I use the latest MAC OSX, here in the home office still Catalina, because it simply runs much smoother at boot time. I have installed Safari 14.0 on Catalina. There it seems to run, but not with Catalina, but from Big Sur. So dear Webflow team, now I guess I’m forced to do this crappy system update to get everything running again.

But what exactly do I do for such users, where the images are just not displayed. I find it totally unprofessional not to offer a fallback - or at least a possibility to undo the process. Now please do not come with the argument that I could import an older backup. Sorry, too much has happened on the site in the meantime.

3 Likes

I’m glad that this is an optional feature.

It’s common practice in my experience to provide a fallback to WebP images (using either the src attribute or a source set within the <picture> element), and Webflow already serves a set of optimized images in different sizes as is. I was surprised to find that this is not the case with WebP.

Browser version usage statistics mean nothing when you’re a freelancer and your client (or a customer of your client) is using Safari on a Mac running Catalina or older. Safari gained WebP support not even two years ago, which is relatively recent considering how glacial Safari development is.

Yes, you could politely ask visitors to upgrade, but in many cases you’re lucky if the user reaches out to let you know—how many others continued to another site since your images wouldn’t load?

Not many, if the sample size of the statistics reflect the whole, but that’s still lost sales, prospects, or even reputation (“that site is broken, use this other one”).

Users don’t upgrade macOS for a variety of reasons—old hardware is one factor (thankfully not as big an issue with Big Sur), but incompatible software is a big factor, especially with those who use their Macs for audio production.

I hope the Webflow team is aware of the issue and is planning to add a fallback soon.

1 Like

Here’s some code (see below) that should fix it for older browsers

Hey! Just ran into this on a client site… But I may have found a solution (see below). It uses a polyfill to support a newer feature in old browsers. It’s converting all your webp images back to jpg’s or png’s on the fly using a Google Conversion Library.

Step 1: Go ahead and load these two scripts in your global site custom code

<script src="https://unpkg.com/webp-hero@0.0.2/dist-cjs/polyfills.js"></script>
<script src="https://unpkg.com/webp-hero@0.0.2/dist-cjs/webp-hero.bundle.js"></script>

Step 2: Add this code to every page on your site. The easiest way I found was to just drop it in a hidden embed in my global nav component

<script>
	var webpMachine = new webpHero.WebpMachine()
	webpMachine.polyfillDocument()
</script>

I don’t have an older mac to be able to test this. But I have spoofed my user agent to an old MacOS/Safari version and it seems to be loading properly.

Let me know if this helps!

Tried this solution but unfortunately it didn’t work