Discussion about using the correct CDN for assets in Sanity and potential issues with multiple requests for the same asset.

Noticing during a component refresh network traffic is fetching the same asset multiple times. I found this to use apicdn.sanity.io instead of api.sanity.io https://www.sanity.io/docs/api-cdn
Currently we are using this dependency
https://sanity.nuxtjs.org/getting-started/quick-start and setting

useCDN: true

but what it's using instead is cdn.sanity.io ? Is there a difference between cdn & apicdn??
I think also we need to adjust the time for "Stale while revalidate" to cache an asset for longer

Noticing during a component refresh network traffic is fetching the same asset multiple times

Would you be able to provide an example of what you’re seeing?

what it’s using instead is cdn.sanity.io ? Is there a difference between cdn & apicdn?

The

useCdn

property is only for document requests (API vs. API CDN), while assets will always use

<http://cdn.sanity.io|cdn.sanity.io>

(and aren’t impacted by that property). There are some more details about the API and API CDN .

In this screenshot these are the same file 206 but not saying (from disk cache). We had a crazy spike in bandwidth last wednesday. idk if it kept requesting videos all day on someone's machine? my best guess
But okay, so the asset.url provided as "cdn.sanity" is expected

I’m probably using the wrong terminology, but could each of those requests be a chunk as part of the complete file?

Looks like 206 is a partial content status, which would seem to align with that.

Do the response headers include any sort of start and end metrics that you could analyze?

I think you're right

i'm not sure, tbh where to look - response tab isn't providing anything

Hmm… me neither. 😅

haha whale I did update everywhere to strictly use cdn and hard refresh - i don't see network traffic for videos anymore and they are playing just fine. Sorry it's been a long day

Oh, great!

I think we're okay. Keeping an eye on it, thanks!

To finish off that previous thought, it looks like you would only expect multiple requests with a 206 status if the content-type were multipart/byteranges. If you’re seeing the type, then the whole thing is in one range, and 206 has something to do with resuming interrupted downloads.
In any event, do let us know if it crops up again.

Definitely it appears what you're saying aligns with what I'm seeing. I'll ping you in this thread if our bandwidth spikes again. Appreciate it!