Understanding the impact of using Sanity's `imageUrlBuilder` on API quotas and bandwidth.

Quick question: does Sanity's

imageUrlBuilder

count towards the API quotas?

We're iterating over some arrays at the moment, and if so, has the potential to fry our quotas pretty quickly given our estimated traffic.

.

as far as i understand, the

imageUrlBuilder

is just a utility that makes URL strings for you. it doesn't make API calls during that process. But then when you fetch the image, that counts towards your API usage.

Got it - and am I safe to assume the images would then apply to the bandwidth cap versus the API CDN cap? Or would it be both?

good question. i don't know actually. maybe someone else knows 🙂

I also don't know for sure but from experience and reading the logs and comparing them with my server logs, I believe that the API CDN cap is for the requests themselves -- the textual returned data, part of which is to identify and return the information about the images.
The bandwidth seems to be a mixture of both -- all the data passing through, in terms of what the queries burp out, and almost certainly any image transformations. I don't believe the actual egress of file data is "cached" in any way in that regard, because, well, being held in memory doesn't make it any less made of bytes and that's what has to get pushed to the end user.

So as you can clearly see.....I
also don't know but used more words to say it 😛

you'd be using both an API request and bandwidth when displaying an image, I believe: 1 call to get the asset and bandwidth in the amount of whatever size that asset you're serving is.

Thanks for the insight ! On that note, I'm wondering if there's a more efficient way to do what we're doing. Ex: we have a landing/gallery page that lists out many cards (with thumbnail images) that link to the respective detail pages. A single query grabs the refs to all the images, but we're looping over that dataset in a Vue template and calling the URL builder for each image, which could potentially lead to dozens of API calls on that page alone.
Is there a better way to handle that?

Good question! You can expand the asset ref in your original query to get the image url, then add whatever params you need using string concatenation on your frontend. That means getting all of those urls is a single call, not 1 call x however many images you're building a url for. The downside is that you're not getting the benefits that the builder affords you (I.e. respecting crop & hotspot automatically).
If you want to continue using the builder, though, you can mitigate the impact of these calls by using the CDN (which affords you about 5x the number of calls).

Awesome, will have a deeper look.