High API usage for 1 SVG but not others on same page


On our site, we have 1 SVG that appears to be using a lot of API "media" calls. This is used on our home page, and is consuming ~50% of our API usage based on the report we were provided.

Other SVGs and images on that page do not seem to be listed in the high call list.

The main difference based on my observations is that the SVG in question is being served from the xxx.cdn.prismic.io domain, whereas as all the others are served from images.prismic.io domain.

Can you confirm that:

  1. Images served from images.prismic.io do NOT count towards the API calls
  2. Images from xxx.cdn.prismic.io DO count towards API calls
  3. Why the discrepancy?
  4. Now that SVGs are no longer supported as image types according to other community posts, what do you recommend doing to reduce API calls for SVGs

Hi @matt.davison. Images served from images.prismic.io and SVGs served from xxx.cdn.prismic.io both count toward API calls.

Are they cached differently though? Cos my understanding is an API call is only counted in usage for an un-cached hit. Is that correct?

I'm trying to understand why we seem to be getting higher API hit counts on assets loaded from cdn sub-domain compared to images.

What else could be the cause, assuming my understanding is correct?

SVGs are treated as files/assets rather than images because of security concerns. The bandwidth counts for all the assets + JSON being downloaded through our API. This means that if an SVG of 5MB is being downloaded 10 times during a month by different users, the total bandwidth will be 50MB.

To this, we add Json's bandwidth for API calls. If a static site generator queries our API for 20 pages that weigh 150KB, the bandwidth related to API calls will be 3MB. At the end of Each period, we are adding all Assets + JSON Bandwidth to consolidate their total Bandwidth Consumption.

If a specific SVG is causing 5M calls, it’s because the website or its users have requested it 5M times. This could be a logo or something present on many pages. An image present on only one page with few page views will have far fewer downloads.

All that to say, your team has probably added some new SVGs on some prominent pages, so it has driven up your bandwidth consumption.

The remedy here is to replace any SVGs with PNGs or similar image formats. Images don’t count towards this total.

Thanks @Phil for that explanation. However, it's not the bandwidth size I'm concerned about it's the number of API requests to try and get it within our cap of 10M and avoid overages.

However from what you're saying EVERY request to for an asset when a browser renders the page is included in that API count, plus the size is in the Bandwidth. That count is the same regardless if:

  • It's served from images or cdn sub-domain
  • It's a PNG or an SVG
  • It's already cached in your CDN instead of coming from the origin storage

Assuming the above is correct then the only way to reduce the API calls is to reduce the images on our common pages (e.g. Home page).

Is that correct, or are you saying that PNGs are not treated as asset API calls, and only consume bandwidth (not API calls)?

I must say the term API call is a little confusing / misleading either way. As these are not calling your API endpoints.

Hey Matt,

Can you send us a direct message on our support portal? Then, we'll be able to run reports on your repository so we can clarify things for you there with more detailed and sensitive information about your repo usage.


Thanks :slight_smile: