WebP support detection issue

LScache webp detection checks in User-Agent the OS Version number, because only Safari on MAC OS (not Chrome or FF) sets the version number in UA and if version is >13 this has webp support. The problem is that Apple has a horrible version control with OS version, OS names and safari browser that makes it almost impossible to detect especially webp support if the version number of a OS special build like Monterey differs from other Apple OS versions.

It would theoretically be possible to adjust webp detection, but this would have far-reaching consequences that would be difficult to control because it involves uncontrolled interactions. Apple (Safari) is basically the new MS Internet Explorer and is trying to establish its own standards, but these cannot be enforced.

As far as your problem is concerned, I think it’s impossible to solve this. But this is not a problem of LScache, but a general problem. The simplest would be if Apple would do it like all other browser manufacturers and would specify webp support in the Accept header.

For reference, MacOS Montery is not a ‘special build’ it’s the current MacOS version (12).

LSCache clearly is not checking the UA header for Safari version as you have described because otherwise, it would work on my MBP which includes the following UA request header (Version/15.6.1)…

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.6.1 Safari/605.1.15

It’s a little reductive to refer to the as my problem. Safari is the second most widely used browser.

Okay, you believe you know it better, so please check the rewrite rule for cache vary and describe what this rule does.

RewriteCond %{HTTP_USER_AGENT} iPhone.*Version/(\d{2}).*Safari
RewriteCond %1 >13
RewriteRule .* - [E=Cache-Control:vary=%{ENV:LSCACHE_VARY_VALUE}+webp]

LSCache clearly is not checking the UA header for Safari version as you have described because otherwise, it would work on my MBP which includes the following UA request header (Version/15.6.1)…

Of course it does, because there is no other way to check it.

• This reply was modified 2 years, 6 months ago by serpentdriver.

But there are other reasons why webp isn’t used.

1.) If the webp version of an image isn’t smaller than .jpg|png version then webp images are not used.

2.) The cache vary to detect the Mac OS version expects iphone and a OS version > 13 to use webp images. This vary is wrong because it doesn’t consider desktop Mac and iPad, so it should be corrected.

• This reply was modified 2 years, 6 months ago by serpentdriver.

Wow, the arrogance is so unnecessary but also hilarious given the massive own goal you just scored.

because only Safari on MAC OS (not Chrome or FF) sets the version number in UA and if version is >13 this has webp support.

Except it doesn’t work for desktop/laptop, as you finally agree with in your last bullet point, which are the only apple devices that actually use MacOS (as opposed to iOS)

2) The cache vary to detect the Mac OS version expects iphone and a OS version > 13 to use webp images. This vary is wrong because it doesn’t consider desktop Mac and iPad, so it should be corrected.

In other words, it doesn’t do as you initially described and in fact my initial statement is entirely correct. Thanks for agreeing and thanks for the totally unnecessary sarcastic, arrogant, rude (and incorrect) response.

Safari v15.6.1 and MacOS Montery(v12.5.1) has full support for WebP so there appears to be something wrong with the WebP support detection LSCache is implementing.

Customer service clearly isn’t your strong suit.

• This reply was modified 2 years, 6 months ago by miketemby.
• This reply was modified 2 years, 6 months ago by miketemby.
• This reply was modified 2 years, 6 months ago by miketemby.

Safari >= 14 on iPhone will have webp

but the issue is on macOS

this is bit of “historical” issue

back the when Safari 14 first released , Safari 14 + Catalina = webp OK , but Safari 14 + Mojave = webp no OK

and in Chrome , it has accept header with image/webp on main request, but Safari doesn’t put this on accept header

as there was no way to differentiate Safari from Catalina or from Mojave , as better safe than sorry , the macOS’s Safari webp detection was dropped

if Safari 15 can not be installed Mojave , then I guess we can simply add detection for Safari version >= 15. ?

@qtwrk unfortunately, I believe Safari 15 can be installed on older MacOS versions such as Catalina where WebP support does not exist.

That said, as of 3 days ago, Safari 16 is out and is only available on Big Sur and Montery and has full WebP support without exception.

So, while it does not address issues with missing support for Safari 15xxx, you can be certain that if Safari version >= 16 it will definitely have support.

FYI Safari 16.0.0 still does not add image/webp to the accept header ??
Maybe in 2025…

In the future MacOS version detection issues may be resolved with Accept-CH: Sec-CH-UA-Platform-Version response header, but as this would only be relevant to subsequent requests, it wouldn’t solve initial WebP support detection for the first request. Safari may not implement it anyway so who knows.

I think Catalina is okay , as long as Safari 15 can’t be installed before Catalina , Safari >= 15 should be okay I think ?

also , as a dirty workaround

RewriteCond %{HTTP_ACCEPT} "image/webp"
RewriteCond %{HTTP:CF-Connecting-IP} !.* [NC]
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule ^(.*).(jpg|jpeg|png|gif) $1.$2.webp [T=image/webp,L]

you can use this rewrite rule to forcefully load webp on supported browser if the request to individual image has image/webp and webp exists

the URL will remain same as something.jpg but the format , content, size , will be loaded from something.jpg.webp

I don’t have a platform to test Safari/Catalina but according to caniuse, webp is only supported on Big Sur onward with Safari 15.

“Safari 14.0 – 15.6 has full support of WebP, but requires macOS 11 Big Sur or later”

Incidentally, I am using BunnyCDN to deliver WebP at the moment and they are able to detect support with Safari 15 where LSCahce does not.
I asked them how they are detecting it but they are unwilling to share the technical details.

Thank you for the above. I will leave it for now as I find the BunnyCDN solution to be a lot more streamlined anyway. No need for the QUIC.cloud account, no need to wait for webp generation and no need to store them locally.

I was testing the LSCache solution to determine what configuration of Cache/CDN provided the best performance. I’m going to leave the caching to LSCache and the image optimisation to BunnyCDN.

I think they did it by the way I mentioned above as my dirty workaround

since CDN handles individual images requests, so it doesn’t involve PHP , so can use that accept header to check webp support

from plugin side , it is more difficult as it needs to determine the Safari from the main request, not image request.

I did a clean install of Catalina on my MBP a couple of weeks ago which meant that Safari was installed with the new system. With all updates made, WebP images are not showing.

Base on the information above, I’m now attempting an update to Monterey to see if Safari 16 will clear the issue.

As a web site owner, my main concern is more that there’s a segment of the population out there who can’t see WebP images in my posts, rather than my own ability to see them.

@dereklc

Did you know that .webp images are only loaded if the webp version of an image is smaller than the origin images?

Compare file size:

https://cdn.digitalserviceslab.com.au/wp-content/uploads/2018/05/Icon-White.png.webp

https://cdn.digitalserviceslab.com.au/wp-content/uploads/2018/05/Icon-White.png

@cachecrawler

thanks for that cachecrawler. Yes, I did know that and that seems to be the point of WebP. If you do a Google speed test on your site, often the recommendations include the use of WebP images to reduce overall file sizes and achieve faster loading time.

I’d be more comfortable with it if it also worked the other way: if the browser couldn’t display WebP, it would substitute the comparable jpg. That would kind of solve the viewing problem, wouldn’t it?

Yes, I did know that and that seems to be the point of WebP.

No, this is a custom workaround of the cache plugin.

That would kind of solve the viewing problem, wouldn’t it?

It already works like this.

Btw. forget .webp. Not the future, but the present is already .avif.

https://www.cachecrawler.com/tmp/Icon-White.avif
https://www.cachecrawler.com/tmp/Icon-White.webp

Compair filesize.

@serpentdriver

Sorry, don’t know what you mean by “a custom workaround of the cache plugin”.

And it may works like this with the updated Mac OS X/Safari set up (now that I’ve updated, I will find out), but it didn’t work that way with Catalina/Safari 15 — I only got broken link images. And as I mentioned before, as a site owner I’m more concerned about others who still have that set up being unable to see images on my site.

And .avif is not without its issues either. I see messages that say: “It looks like you’re running your site on an NGINX server. You may need additional configuration for the AVIF delivery to work as expected?.” And some hosts won’t let you play with that configuration.

I’ll wait on avif to see how that works out…

Thanks for all the info — I DO appreciate it!