I have implemented Image Resizing using the URL format approach. It’s a fast and cool solution but now I’ve released it into production it seems that resized images are ineligible for Cache Reserve.
This limitation makes Cloudflare Image Resizing is a very expensive tool compared to competitors (Cloudinary etc.) that do not constantly evict your resized images and charge you to recreate them.
From looking at other threads, there are plenty of other people who have been similarly confused by this peculiarity and understandably expected that the resize counts would be much smaller.
Are there any plans to change this so that the resized images are stored in Cache Reserve? If not, it feels like I’m in a slightly ridiculous situation here where I may as well put two Cloudflare domains in front of each other - one to do the resizes and one to put them into Cache Reserve. Has anybody tried that?
Unfortunately, we also found out that images from image-resizing do not run in cache reserve, and generally no page-/cache-/etc-rules can be applied to image resizing. This is a pity and makes it (as you described) much more expensive than it could be.
I’m very sure that your idea of running two Coudflare instances in a row will work. We are making do with similar constructs.
Is super inconvenient that you have no influence at all on how long an image resized via Cloudflare sits in the caches and when it has to be regenerated (on charge). We have images that are resized to the same size (=and of course billed) by Cloudflare more then 40 times a day. They’ve could been easily cached in cache-reseve.
so it really is the case that CF can cache images that are resized by a third-party provider wonderfully, but not their own
Cloudflare kindly reached out after I posted this thread. They are aware of the issue and actively working toward a solution that will make the offering more compelling and understandable.
It transpires that there are technical reasons why Cache Reserve can’t be used and the issue is worsened by the fact that images get evicted from the cache quite quickly compared to some other objects. This then causes the excessive transformations we’ve seen.
Hopefully we won’t have to wait too long for news.
