Cloudflare Images: Single request of an image counts as two images served

I’m seeing an issue the past couple days where each request of a single Cloudflare Image is showing in the dashboard that two images have been served.

The minimal reproduction of this is no normal traffic to Cloudflare Images URLs and using the dashboard to preview an image. Loading the image once increases the images served count by two.

The same happens when visiting the typical delivery URL directly: https://imagedelivery.net/:account_hash/:image_id/:variant_name

I’ve tried quite a few more scenarios;

  • Loading an image using a custom domain URL https://example.com/cdn-cgi/imagedelivery/:account_hash/:image_id/:variant_name
  • New and previously uploaded images.
  • Images of various extensions and sizes: GIF, PNG, JPG, 100b to 9.5mb
  • Different Browsers on different platforms: Chrome, Firefox, Safari, Windows, iOS
  • Using image tags on multiple different domains including ones not on Cloudflare. (to eliminate possible favicon requests)
  • Using a browser that does not use accept headers. (to avoid WEBP and AVIF)
  • Various combinations of all the above.

I tried to eliminate possible configuration issues by using the imagedelivery.net URL directly however all testing showed that one image requested results in two images served.

Is this an isolated issue or have others seen the same problem?

Edit: I forgot to mention I only have a single variant, the default Public variant which I have not modified and that the website is closest to a forum or image board.

2 Likes

I treid, and counted as 3 few minutes ago → maybe because I clicked at “Preview” counted +1, therefore copy-pasted the imagedelivery URL into the browser and this counted +1, but where from did anote +1 counted … not sure, maybe as it’s a JPG and I see it as optimized AVIF in my Web browser?

Maybe not, but could be due to the fact that I have 3 variants, so Images had to regenerate (first time open) for all 3 of them, while I openned only one variant URL in my web browser?

UPDATE:
Now I clicked on a Preview image of recently uploaded, one variant then clicked on the “right arrow” to see the other variant (not copy-pasted and not openned it directly by the URL in my web browser)
It was counted correctly, +2.
IN between copy-pasted the URL, 2-3 minutes later I openned one variant which I copy-pasted in new tab of my Web browser.
Closed.
Refreshed the Images tab, and I do see it counted +2 (as there are 2 variants of this image).

I think it’s due to my Web browser as far as it supports jpg/png/gif and new WEBP and AVIF.
Therefore, the original request goes to JPG, but I got served with optimized AVIF.

When a client requests an image, Cloudflare Images will pick the optimal format between WebP, PNG, JPEG and GIF. The format Cloudflare serves to the user is determined by client headers and the image type.

Can Cloudflare Images convert my images to AVIF or WebP?

Yes. Based on the Accept HTTP request header Cloudflare Images will be served in AVIF or WebP format. The transformation of an image to AVIF is compute-intensive but leads to a significant benefit in file-size. We are always weighing cost and benefit when deciding on which format to serve.

I am not 100% sure if I am correct about my statement, but that’s what I assume (due to the my web browser/client accept headers).

Nevertheless, may I ask if you are worried about getting charged for that?
From the docs it says:

Do I get charged for creating and storing variants?

No, you only get billed for the number of original images. There is no extra cost for generating variants. You can configure up to 20 variants.
Source: https://developers.cloudflare.com/images/faq#do-i-get-charged-for-creating-and-storing-variants

Pay only for images stored and served

Images are priced at $5 per 100,000 images stored and $1 per 100,000 images delivered — with no egress costs or additional charges for resizing and optimization.

2 Likes

Thank you for testing this. I should have mentioned, and have updated the original post, that I only have the default Public variant which I have not modified. I had not considered that regenerating an image for browser using accept headers might count as another serving.

I tested this in another browser that does not use accept headers using the imagedelivery.net URL in an image tag on a domain that is not connected to Cloudflare. The image was served as a png from a single request and has still been recorded as two servings.

Found using the “change subscription” button on the Images tab in Cloudflare dash:

Resizing: Free
You can create up to 20 variants.

Storage: $5.00 per 100,000 images (prepaid)
You only pay for the original image. If you have 10 original images with 5 configured variants, only the 10 original images count towards your storage limit.

Delivery: $1.00 per 100,000 images served (postpaid)
You will only be billed for number of images served.

The main concern is the “billed for number of images served” and receiving 50% of the images served for the price paid. If 100k images are displayed on the site, the charges would be for 200k instead. From the testing I have done, even if an image is found in Cloudflare’s cache a serving is still added to the account. (Two servings on this account) It seems like the costs could rise very quickly, especially if every image is delivered at twice the serving price.

If this is a configuration issue related to my account I would like to be able to identify the issue. There aren’t many options considering Cloudflare Images is linked to an account and not a website. Especially considering this is still occurring when using the imagedelivery.net URL in an img tag on a domain and hosting that is not using Cloudflare.

Without knowing what kind of type is your webpage, I can only say using Cloudfalre Analytics and Caching Overview (if possible), you could try to determine which content-type is mostly downloaded and to which most requests go (despite being cached or not).

For example, in last 24 hours for one domain with enough web traffic per day, I have:

  • 133k webp request (served?)
  • 105k svg request (served?)
  • 40k jpeg request (served?)
  • 77k gif request (served?)
  • 14k png request (served?)

But, all that is served from my origin as the origin/server is hosting them → not yet using Cloudflare Images for this case, rather only testing on few domains.

Just to think about, what would “bots” and “crawlers” do in this case as the daily visit our websites and gather resources (images, css, js …)?

  • bingbot, googlebot-image, applebot, preview links on social networks (not sure), etc.

I am afraid, In this case you would have more than 200k served so far per month.

In that terms, kindly I’d suggest you to write a ticket to Cloudflare support due to your concern and possible issue and share the ticket number here with us so we could escalate this if so:

  • Login to Cloudflare and then contact Cloudflare Support by clicking on the Get More Help button. If you get automatic reply, reply and indicate to it you need more help and reference to this topic
  • Or send an an e-mail to support[at]cloudflare[dot]com from your e-mail associated with your Cloudflare account
1 Like

You make a solid point: The website is closest to a forum or image board.

It is not currently using Cloudflare Images. From running some tests it appears that about 35% of all requests and 90% of data transfer are for images (50% PNG, 20% GIF, 20% JPG). About 60% of all bandwidth and 30% of requests is handled through Cloudflare cache. Requests for this test was about 20k total with images making up 7k.

I suspect that there would be more requests for images but are instead handled by user’s local cache as a single page (thread/post) could easily have 20 images. Relying only on user cache to keep costs down sounds like a loosing battle. I do have longer local cache headers set, but it is possible that users are accessing the site in a way that is not compatible or have them overridden.

Another solid point. During this test between 500 and 1000 requests were from bots or crawlers. It is not a large concern during this specific testing as they should not have access to pages with images. I had not considered preview links however and it seems they could easily increase the total number of requests.

I’ll contact Cloudflare support by email about the concerns and possible issue. Thank you again fritex for your time and assistance.

Edit: I sent an email to support and the Cloudflare Support Team (Bot) set the status to solved. “We have automatically detected that you may not be the account owner of the domain(s) mentioned in this ticket.” The help center request id is #2365919, but if it cannot be reopened I’ll send another email at a later time with all mentions of imagedelivery.net and community.cloudflare.com removed.

1 Like

Thank you, I’ve escalated it.

Kindly and patiently wait for a reply.

2 Likes

Looking at it now.

1 Like

Replied in the ticket, We have escalated the matter internally

I saw the same thing today, and it also counts 404 response as delivered image :joy:

2 Likes

any updates ?

1 Like

I went through the reproduction steps earlier today while testing the new direct upload URL API and I’m still seeing the issue. I checked in on the currently open ticket before the weekend and I’ve been informed the issue is still being worked on.

I tried to replicate the 404s you saw counting for image delivery, but I only got 403 and 400 with ERROR 9425 (“URL signature is required” and “This account doesn’t have variant with this name”) which didn’t seem to increase the images served number in the dash.

to reproduce the 404 :

  • Upload an image
  • request the image and see it
  • delete the image from dashboard
  • request the image
  • you will see that the counter increment

I upload one image, view it onces, yet it showed serving 4 times in the counter. This still lack a lot of features and needs improvement.

Hello

The matter is with our engineering team.
We aim to update as soon as we have further details.

2 Likes

We have not heard back yet, but I asked for an update on the status, and we will provide that as soon as we hear back.

3 Likes

This issue has been confirmed by the Cloudflare Engineering team & are working on a fix.
(Post fix will then also review the accounts review element of the matter).

2 Likes

Tnx for an update :+1:

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