Get help on Discord

Why is my Sanity bandwidth so high for a static site with few images?

13 replies
Last updated: Mar 5, 2021
Can someone explain to me how my bandwidth can be so incredibly high for a static site that is only using roughly a dozen images?? This site has been live for 9 days and the bandwidth spike seems absolutely wild for what this site is:
AI Update

I can totally understand your frustration! High bandwidth usage on a static site with minimal images is definitely concerning. Based on similar cases in the Sanity community, here are the most common culprits and solutions:

Common Causes of High Bandwidth

From a very similar case that Sanity engineers investigated, here are the typical issues:

1. Image Quality Parameters (q=100)

Setting q=100 on your image URLs significantly inflates file sizes without noticeable quality improvements. Switching to q=80 can reduce bandwidth by ~30%. For example:

  • q=100: 1.2 MB
  • q=80: 281 KB (same image!)

2. Oversized Width Parameters

Using w=1200 or w=800 when images are displayed smaller, or when the original is already smaller than the requested size, wastes bandwidth. Only request the size you actually need.

3. Large File Assets

PDFs and other document types served through Sanity's Asset CDN can be several MB per request. If users are frequently downloading menus, brochures, or other documents, this adds up quickly.

Quick Fixes

  1. Optimize your image URLs: Use q=80 instead of q=100, and set width parameters to match actual display sizes
  2. Check for large files: Look at what PDFs or other assets might be getting downloaded repeatedly
  3. Review your image builder configuration: If you're using @sanity/image-url, make sure you're setting sensible defaults

Debugging Tips

The bandwidth spike dropping off on weekends suggests it might be related to:

  • Studio preview activity during business hours
  • Automated processes or bots hitting your site
  • Client editing/previewing content

Check your Sanity project's usage dashboard to see which assets are being requested most frequently. The Asset CDN caches aggressively (up to 10 MB images indefinitely), so repeated requests for the same URL shouldn't cause bandwidth issues unless the URLs are changing.

If you need help investigating further, Sanity support can look at your logs to identify the specific assets causing high bandwidth usage. Just reach out with your project ID and they can provide detailed insights into what's consuming your bandwidth.

Show original thread
13 replies
Not sure what the cause of the usage is but last month someone did find a work around that really cutback bandwidth: https://sanity-io-land.slack.com/archives/C9Z7RC3V1/p1610183363450900
Hi User. That is indeed a lot of bandwidth usage. It looks like the bandwidth really declined over the weekend so I’d be curious to know how your studio is configured (whether you’re using previews, etc.).
Thanks
user M
- the cloudfront solution is interesting, but I don't love the idea of introducing yet another service to manage, and have the client pay for, for something I feel should be already be happening at the sanity level.
user A
yea, what info can I provide about my studio that would help give you insight? There is a preview option within the studio for pages, but I honestly don't believe the client has really leveraged that since we built out the current content together before launch. Since the spike in bandwidth was after launch, I'd highly doubt that would be causing it?
I see what you’re saying, and hopefully one of Sanity’s engineers can give you some insight (I’ve put in a request for you). The thing that stood out to me was that bandwidth usage seemed to really drop off over the weekend, which leads me to believe it’s something happening in the Studio from Monday-Friday (when I assume your clients are working in it). Perhaps some details about your stack (Next.js, Gatsby, 11ty, etc.) and tech used (SWR, ISR, etc.) could offer an ah-ha moment.
If it’s the site I think it is, everything looks efficient on the front end (images are optimized, etc.) so I imagine anything going too crazy there would be clear in your analytics. I hope this can be figured out for you quickly!
Thanks so much
user A
! Here's some more info about the site:• Site in question:
https://cotemiami.com/ • Built on Next.js, hosted on Vercel
• Image assets are using the sanity image-builder: @sanity/image-url
• sanity client has 
useCdn
flag set to true in production (only turned off for dev or preview mode)• None of the pages are server-side rendered, all are SSG
Ahh, okay. That’s a different one than I thought so I’m glad you clarified. I got a bit over 20MB of transfer when visiting the home page. Is that rendering in the Studio preview?
user A
thanks! And nah the rendering and other video loop at the top is loading static from the project (so should be hitting bandwidth on the Vercel side of things)
I figured allowing video upload on the sanity side of things would be a surefire way to balloon the bandwidth, so I kept it out of there (and really, they should be on Vimeo if I wanted to avoid bandwidth usage on Vercel too)
DM me the project ID and I can have operations look into it?
Hi User, I checked out some logs and it seems like the main culprits for high bandwidth are:• Large PDFs such as menus (up to 3 MB per request)
• 
q=100
quality parameters in images, which probably inflates file size without improving image quality vs something like 
q=80
. I think this alone could lead to a reduction of ~30% in bandwidth• 
w=1200
or 
w=800
on images that are shown at a smaller size or have originals that are smaller than the defined size. Optimising these will probably deliver additional savingsAn example of the last point is the attached area on the home page, but it also occurs in larger images:
• Current image URL -
https://cdn.sanity.io/images/1je3os9g/production/e0e3bf999e269cc88da404d9adf72e68d80c689a-801x1202.jpg?w=1200&fm=webp&q=100 (inflated size + q=100) = 1.2 MB• Optimised image URL -
https://cdn.sanity.io/images/1je3os9g/production/e0e3bf999e269cc88da404d9adf72e68d80c689a-801x1202.jpg?fm=webp&q=80 (original size + q=80) = 281 KBHope this helps!
Interesting, thanks
user A
and
user M
! I'll let them know about the PDFs, didn't even think to check those out, but I agree those are massive (and probably what visitors are looking at most). The image inflation is also a good catch. I appreciate the insight on all of this! 🙌
Hy User,I'm having similar bandwidth problems with a site that is built on the same stack (sanity, next.js, vercel) and I wanted to ask, if you were able to resolve your problem? (and if yes, how?) Best regards
User

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Get started for freeExplore the demo

Was this answer helpful?