Cloudflare CDN Cache To Support HTTP Vary Header

Currently Cloudflare CDN cache doesn’t seem to support HTTP Vary header as per


Cloudflare cache doesn’t respect the vary header

This means if you’re on Cloudflare free plan without access to Polish’s webP support, you can not properly implement webP support on origin server side as Cloudflare CDN cache won’t be able distinguish whether Safari web browsers will serve non-webP images from origin server as Cloudflare CDN cache may have previously cached a webP mime-typed served image to webP supported browser visits from Chrome/Firefox.

End result is on Cloudflare CDN cached .webp origin images get served to web browsers that do not support webP i.e. Safari. Example of the issue is outlined at WebP & Safari Browsers - any suggestions?

Right now I have had to disable Nginx origin webP support if Cloudflare is detected for sites because of this as outlined at

map $http_accept $webpok {
   default   0;
   "~*webp"  1;

map $http_cf_cache_status $iscf {
   default   1;
   ""        0;

map $webpok$iscf $webp_extension {
  11          "";
  10          ".webp";
  01          "";
  00          "";

So Nginx only enables webP origin support if Cloudflare cache is not detected and browser HTTP request headers support image/webp mime type and disable webP origin support when Cloudflare cache is detected.

This is mainly an issue with Cloudflare free plan as paid plans have Polish webP support.

So suggestion/request is for Cloudflare CDN cache to support HTTP Vary header if possible.

If you use Cloudflare and nginx you should not be forced to pay for webp support.


Hi Eva, thank you very much for reposting this here! I hope there will be a solution for this in the near future. For now, I have found another third party solution. I’m using shortpixel’s CDN for WebP Delivery and resizing now and it seems to work quite nice at the moment. Much cheaper than the cheapest Cloudflare plan. But, of course another plugin to be used which is annoying. Would be much better if Cloudflare and Siteground would figure out a solution for their customers… Cheers Patrick

1 Like

Hope that Cloudflare will add this …

1 Like

I found this discussion when searching for whether CF supported Vary. I was looking at adding this to a current project and fully expected support. I don’t have my notes in front of me, but I think this is also why we can’t use WebP. We’d certainly take advantage of this. Currently I work around it by using custom cache keys.

1 Like

Hi John, so are you a SG host member? I am n the GrowBig plan, have decided to purchase the Cloudflare Premium $11.95/ month through SG so to get this WebP going. SG tech have given me such differing answers, I am so confused. They have now advised they have redirected DNS to CF. Honestly Im not holding my breath for the next 72 hours while waiting for that to click over. I really dont want to be compressing images prior to upload onto website; I have so many already there; just want to do a bulk compression and move forward. Can you suggest next step for me? ** am learning as I go

I’m sorry, I’m not sure what SG is. I am on an enterprise plan.

Hi John, SG is Siteground. Update: SG are now telling me I have to rewite my URL - it involves things like re-directing root directory, .htaccess modification ect
This is getting too complex, I need an IT degree. Does it have to be this difficult when on cpanel with Siteground, I cant wait another 8 months for the upgrade to have WebP capability…

Hi Patrick, Ive just wasted 5 days (with my limited knowledge) trying to get SG & CFlare Premium plugin working to get my images compressed to WebP. Ive given up. Still have the one month CFlare premium plan paid (the polish module included) and active which I purchased through SG … can I get some info on what to do next from here in order for WebP to load on browser? SG Techs have absolutely done my head in - they all gave overriding information of each other … so much that Ive deactivated their SG optimiser plugin - really dont want anything else to do with SG - I am afraid to make the full move though - am really upset at this point - they handled it all quite poorly. Re: WebP - I believe I got it all to a point where my images compressed however did not deliver to browser - something was in the way… also I didnt like enabling redirects - I believe this would make my Google speed lower (as it is already low ~30)

Any updates on this? Or tips on how to get around webp cached content going to devices that don’t support it?

I built my own on-the-fly image resizer which delivers webp if the client has the appropriate accept-header and jpg/png if not. I add a ‘vary’ Accept header and caching works fine on Cloudfront and Firebase (Fastly I think), but I have been using Cloudflare since day dot for all my projects so keeping the CDN on there makes sense, and there are genuinely a lot of benefits to their CDN implementation.

Are you generating WebP images locally?

Not sure what you mean by locally in this case. They would be generated on the fly in a Google Cloud Run container.
Bucket Image storage is jpg and if user request accepts .webp then that image is resized and transformed and .webp is served in place of the jpg, if the user doesn’t accept .webp then it is just resized.
So both options need to be cached to support both scenarios.

You can use JavaScript to detect Browser support and serve WebP. In WordPress CMS, a popular plugin called EWWW has such feature.

One way I found is not saving origin served webp files with image.jpg.webp or image.png.webp but instead image.webp and instead of using server side conditional serving of webp, use data-srcset/picture method saved in HTML so that the right browsers render the webp when supported (even when Cloudflare has cached HTML).