I recently learned that the image filenames don’t change, but the file type does show it’s webp as it serves the optimized image. This shows up in a browser’s Dev Tools or a performance tester such as Webpagetest or Pingdom.
I’ve just upgraded my Cloudflare account to Pro to enable both Polish (lossy with webp) and Mirage. After purging the cache and hitting the site a few times, I can now see most images (JPG and PNG) are now being served as webp which is great.
However, there are still some png’s and jpg’s that aren’t served as webp. Checking the response headers, the usual cf-polished keys are not there. I have no idea why these seem to have been excluded by the polish feature.
Can someone shed some light? These images are stored on the server just like all others that have been successfully "polished’.
Appreciate any help.
I’m seeing this same issue. We upgraded to Pro earlier today. I’m very familiar with clearing the cache (many times) and checking the headers using Chrome dev tools. I have yet to find an image that leverages the cf-polished header. I do see other CF headers, but none related to Polish. What gives?
@adam.sembyotic Can you run a PageSpeed insight and see if it shows “serve images in next-gen formats”? Cloudflare won’t compress/re-encode images with polish if transitioning them to the new format would increase the size of the image.
PageSpeed does show “transition to new formats”. Thoughts?
Make sure the resources actually come from your cloudflare-protected domain. External resources form other domains cant be optimized.
I tested a Pro site of mine and I’m getting the Polish header…but only after getting a cf-cache-status HIT on the resource.
Thanks for sharing this @sdayman, this got me to think of in a new way. I noticed I wasn’t getting cf-cache-status at all, which prompted me to look at my page rules. Sure enough, I had a rule enabled that was bypassing the cache for anything inside of a wp-* folder. I’m not sure why that rule was there, but turning it off is now showing results. Unfortunately, the larger images don’t seemed to be caching yet. I’ll keep an eye on it, but for now at least one problem is solved.