Jpg images are randomaly not loaded on Safari 13.1

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.


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!)


Once available that should actually address it, as you’d remove the webp announcement altogether, hence that server-side tool will still cover resizing but won’t convert the image, which then - as you mentioned - will be up to Polish.

Current problem, it’s not publicly available :slight_smile:

1 Like

That has the same effect of just shutting down WebP conversion at the server, right?

1 Like

Yes, essentially. You remove the accept header and the origin won’t know about webp. Question is what happens when you remove the header altogether, adjusting might be better.

Should be. The Origin should use the Accept header to determine the Client capability. If the Origin refuses to give that capability, removing the header should tell the origin to not transform the image.

1 Like

@simba a lot of good recommendations have already been made. Maybe one will fit your needs.

I anyway would still like to throw another one into the round:
native solution.

Take a <picture> tag and overload it natively. For this solution you dont need Cloudflare are you optimize your site for ALL end-devices the same, but it still works perfect in combination with Cloudflare. This does not exclude anything.

        <source srcset="/img/picture.avif" type="image/avif">
        <source srcset="/img/picture.webp" type="image/webp">
        <img src="/img/picture.jpg" width="800" height="1200" alt="ALT TEXT">

This then turn off Polish and turn on Cache for the respective folders. in this case:
Cache: Cache Everything
Edge TTL: 1 Month
Browser TTL: 1 Year

I implement this on ALL my sites and have never used Polish. Its a nice feature but actually for me works to much “one sided” so I never used it.
This method with an overloaded Picture Tag comes with 1 downside:

You must be able to generate your wished NextGen formats (WEBP, AVIF, JP2000 whatever you want) on your origin server. But if you are able to this in my eyes is the perfect native solution that will work on ALL devices with all advantages of Cloudflares CDN functions. Also this makes your optimization wise independend from Cloudflare and you can generate (for free) as many NextGen pictures as you want, you just need a server for.

What I would not (actually NEVER) recommend: rewriting WEBP with reqriterules! Dont use .htaccess rules or Nginx rewriterules for such things, it will not able to be proxied. Well it is, but it breaks functionality for some clients.

Yes, thats what I tought about. This will ofc result in:

  • clients which uses browsers which do not support “webp” are getting served slower. For that reason this is not a solution, just concealing the problem. For a real solution I would recommend the post above this.

@sandro we have no issue with switching to the paid version. The issue is that we’re unable to disable the server-side webp conversion without switching from using the Next.js image component entirely, which means losing a lot of other benefits.

@M4rt1n that’s actually the approach that we just switched away from :joy: We wanted to ditch the overhead of creating and storing our own variants. The Next.js team is working with Google’s site speed engineers to create this component and we believe they will continue to improve it in a way that is better than a native solution. For the most part, that has worked perfectly…it’s just Safari 13.x that’s causing issues. We are open to consider switching back to a native solution and upgrading it to handle multiple sizes better. But for now we will continue to look into your solution and also the Header Modification Rules (@michael we will email you about that).

In that case, your best bet - for now - would be to contact Sam at smarsh at and ask to have that feature enabled for your account, at which point you could use it to remove the Accept header, which should stop your server from converting the image.

Then you simply enable Polish to have it converted on Cloudflare’s side. In that way you could keep your server-side tool but also Cloudflare’s caching and still serve WebP files wherever applicable.

Once Apple made MacOS 11 available (in around four months) people typically upgrade rather swiftly, so in about six to eight months most people should be on a version which will support WebP as well.

Thanks, looks like that’s the way we’re going :slight_smile:

This is looking promising, thanks for the pointer @michael.

I set up the header modification rule to remove the Accept header for all files matching the URI path /image. We’re currently receiving back JPGs from the server though - which is still about 3x faster than un-cached webps so it’s already a win. But it would be good to serve webps to the browsers that support it. Would the best way be to add another filter on the rule based on the UA? If so, do you know a reliable way to detect webp support from the UA?

That’s where aforementioned Polish comes in.

You essentially disabled WebP at this point, but still need to serve it from the proxies and that’s Polish’es job.

But you said you already had that enabled anyhow. So make sure that is properly enabled and configured.

Easiest way: Enable Cloudflare Polish. @ron13 indicated that this was already enabled. Polish takes a few hits before the conversion is completed.

The only way I’m aware of is in the Accept request header, which is why I suggested removing it on the requests to the Origin. If the Accept header contains image/webp it means the UA can understand WebP. But Polish will do that automatically once you enable it.

@sandro @michael again, thanks for the quick replies.

I didn’t realise that Polish takes a few hits before the conversion is complete. Now I see a mix of webps and jpgs loading. I guess it’s a matter of time till all images are loading as webp so it seems we’re all good. Out of interest, do you know why that is?

I had thought that it would be better to strip the Accept header only from Safari 13 and older browsers…currently we are stripping it for all browsers as there is no filter option for Accept header (hence I was thinking to have a filter on the UA to only cover Safari 13 etc). I guess it isn’t doing any harm since the origin server just won’t return a webp and Polish will catch that and return a webp.

Yes, Polish is based on the cache and only files served from the cache will be converted. As long as it still comes straight from the origin it will still be the original file format.

WebP conversion is slow (AVIF is even slower), so the first client gets the JPEG version while the conversion takes place.

What you do not want is for a WebP asset to be delivered from the Origin. Polish will not convert WebP to JPEG, so if you put a WebP asset into the cache, Cloudflare will serve that image to every client, even if the client does not support WebP. If you use Polish, once the conversion is complete, clients will get a version of the image that they support, based on the capabilities they advertise to Cloudflare.

Maybe an easier way to think about this is using the Accept-Language request header. A browser requests, and says ja,en-US;q=0.9,en;q=0.8 in the Accept-Language header, indicating a preference for Japanese. Your origin sends back a Japanese version of the file, with a long cache control header. The next user requests the same file, but Accept-Language says en-us. The cache knows nothing about the Accept-Language header, so it just delivers a Japanese version to the user!

Essentially, the only information the Origin should ever use when generating a response is the URL, if the response is to be saved in a cache. Polish extends that behaviour a little, and allows conversion from JPEG to WebP, but not the reverse.

1 Like

I see, that explains it really well. At some point, I hope that the Next.js image component will start returning images with their extension in the filename so that CF knows whether to return the jpg or webp. At that point, we can start using that rather than Polish…as it would skip the conversion step. For now, glad it’s all working :slight_smile:

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.