It seems this problem is persisting and I am unable to fix it. I switched over from Image Resizing for a project to just Images, delivering the images from my own domain (/cdn-cgi/imagedelivery/…)
When testing with Google PageSpeed now, it complains about the cache time being just 2 days. I can confirm after checking my self I see this:
Thanks… but this issue persists for months. That was the reason I did not use it before and I used Image Resizing instead. I just switched over like a fool now, edited a lot of code, etc…
Not a good look. Why on earth would you set a cache time of 2 days? And why would you even release a service where you cannot specify the cache for images?
It just doesn’t make any sense. Very disappointing.
I absolutely agree with @Mecanik .
We use the Cloudflare Images Service, but have registered our domain somewhere else and therefore have no possibility to use the Transform Rule Workaround mentioned by @KianNH if I see it correctly…
And I don’t understand why the Cloudflare team is trying to solve the problem in a private chat if this problem is relevant to the general public…?
I don’t know, but if I can get a “fix” I will certainly test. What concerns me is the why. Why would you have 2 days cache TTL on the images unless you plan to update the same image URL at some point?
I have been advertising Cloudflare Images services quite a lot and got onboard a lot of people, especially businesses. However this was with Image Resizing luckily.
The Google Lighthouse recommendation for immutable static assets is one year or longer, so that means max-age=31536000 (Serve static assets with an efficient cache policy - Chrome Developers). But the account i am using here is not the account where we use the Cloudflare Image Service for our company.