Jpg images are randomaly not loaded on Safari 13.1

Hi

Here is a quick video showing our issue - Loom | Free Screen & Video Recording Software

Every time we try to cache images, some of them are not loaded.

Would love to get a direction for fixing this issue.

Thanks
Ron

Are you doing any WebP conversions on your server-side? If so you’d be caching them on the proxies and clients which could not handle them would get them too. If that is the case you need to disable that conversion and could optionally use Cloudflare’s Polish feature for that, though that’s paid.

If it is enabled on your server you should disable it, purge your cache on Cloudflare and you should be good to go.

2 Likes

Hi Sandro

Thanks for the info.

We enabled polish and cleared cache.

I don’t think we have anything on the server side.
but we still have this issue on safari 13

Can you please advise on what are we doing wrong here?


is the rule we have

Ill keep it online so you can check.

example URL https://bit.ly/3oDlns4

for some reason, we are serving webp instead of jpgs in some cases and only when CF cache is on.

That’s exactly what I referred to earlier and something you need to check on your server side. Disable anything that is WebP related on your server.

removed webp in this line

location ~* ^.+.(?:jpe?g| webp |ico|gif|png|svgz?|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|psd|pdf|ppt|htc|swf|fla|woff2?)$ {

in nginx

but we still have the same issue.

I’m not sure where else can it be

funny thing it works for most photos … but only a few are missing

This is because not all images will have been cached as WebP. The issue really is that you are caching WebP images on Cloudflare, which then get served to clients which cannot handle WebP.

If you cannot get your server to stop doing that, your only other option will be to disable caching on Cloudflare I am afraid.

1 Like

Or just for domain.tld/*.jp*g
This should make sure you just exclude “JPG” and “JPEG” files from Caching and not to many unnecessary file extensions.

If you do not have any links with “jpeg” as file extension you can also go for:
domain.tld/*.jpg

Now as I think about it. With Workers you could build a little app that will bypass the cache if the visitors browser does not accept the mimetype “webp” :slight_smile:

And that’s most likely the issue. That URL will do exactly what I described. You either remove that page rule (and have no caching) or disable the conversion on your server.

Hi, I am the developer working with Ron on the website. Thanks for helping us dig through this issue.

@sandro I am unclear what you mean about disabling webp on the server end. Are you saying that we can’t use webp images? Or that the server should not do any conversion and that Cloudflare would automagically convert and serve webps via Polish?

If so you’d be caching them on the proxies and clients which could not handle them would get them too.

Is there anywhere documented about why Cloudflare would serve webp images to Safari 13 (and presumably other browsers that do not handle webps)? Or is it that there are other proxies that are not CF-related which are serving them?

I addressed that issue already a few times. What was unclear about the explanation?

I’d also recommend to use the search as this topic has been discussed quite a few times already.

1 Like

@sandro thanks for the info, I searched around and am slowly getting my head around this issue.

It appears that the issue there isn’t an ideal solution.

We do webp conversion on the server via the Next.js image component. This converts to webp but also resizes images - which is useful and I don’t think it’s something that Polish offers. So, while we have upgraded for now, I think Polish only does half the job so we are hesitant to use it for webp conversion.

It’s not yet possible for Next.js to disable webp conversion without also disabling image resizing, although it is requested:

I’m not optimistic this will be implemented.

So it appears that we can disable webp conversion at the server end but then we lose out on re-sizing images. This is not ideal.

That’s precisely the thing I referred to and which you need to stop doing.

In that case you could only go with the other option I already mentioned and disable caching, respectively the page rule in question.

@M4rt1n that sounds promising. So the idea would be that for most browsers, we return the normal cached asset. For Safari 13 etc, we can skip the cache.

So something like this example https://developers.cloudflare.com/workers/examples/conditional-response but with the following differences:

  1. instead of checking the hostname, we check the request header contains webp in it
  2. if it does, handle the request as normal
  3. if it does not, skip the cache

Is that what you had in mind?

1 Like

Right, yes that’s far from ideal as caching is speeding up image loads tremendously. Will look into the worker suggestion from M4rt1n.

A Worker could work but will be a paid feature if you exceed the free limit. Cloudflare has a dedicated feature for that and from your previous response I understand you are already using it. If so, just disable your server-side conversion.

They’re probably just waiting for enough people to update to the latest MacOS/iOS/Safari that’s WebP compatible so they don’t have to implement.

https://caniuse.com/?search=webp

2 Likes

The Header Modification Rules (currently in Beta) will potentially help here. If you look for image/webp in the Accept header, and remove the header (if present), the request to the origin should indicate to the Origin that webp is not supported, and then Polish can act on the response as normal.

(Needs to be tested!)

2 Likes