High bandwidth usage on Gatsby site with Sanity CDN images
Based on what you're describing, I can help explain what's likely happening with your bandwidth usage. The good news is that Sanity's image CDN has very aggressive caching that should work in your favor, but there are a few potential issues with the Gatsby setup that might be causing problems.
How Sanity's CDN Caching Works
Sanity's Asset CDN uses content-addressable URLs with SHA-1 hashes, which means the URLs include a hash of the asset contents. This is actually great for caching because:
- Assets are cached indefinitely once processed
- The CDN supports both Brotli and Gzip compression
- Images up to 10 MB can be cached on edge servers globally
- Cache invalidation only happens if you delete the entire dataset or project
The CDN sets appropriate cache headers that should allow browsers to cache images aggressively, so users shouldn't need to re-download images on every visit.
Why Your Bandwidth Might Be High
Your theory about re-downloads on every deploy could be partially correct, but it's likely related to how gatsby-source-sanity and gatsby-image are handling the image URLs. Here are the most likely culprits:
Image transformation parameters changing: If Gatsby is generating different query parameters for image transformations on each build (even slightly different sizes, quality settings, or formats), each variation creates a new CDN request and counts toward bandwidth.
Multiple image sizes:
gatsby-imagetypically generates multiple responsive image sizes (srcset). For a single image, you might be serving 3-5 different sizes, which multiplies your bandwidth usage. With 1,200 visitors viewing multiple images each, this adds up quickly.Auto-format parameters: If you're using
auto=formatin your image URLs, the CDN might be serving different formats (WebP, JPEG, PNG) to different browsers, which would count as separate requests.Browser cache vs CDN bandwidth: Even though browsers cache the images locally, every unique visitor still needs to download them once. Your Sanity bandwidth measures total CDN delivery, not just uncached requests.
How to Debug This
Check your actual image URLs: Look at your built site's HTML and see what image URLs are being generated. Are they consistent between builds? Do you see lots of different size variations?
Monitor your CDN requests: Use your browser's Network tab to see what's actually being requested. Check the response headers for
cache-controland whether requests are returning 304 (cached) or 200 (fresh download).Calculate expected bandwidth: If you have, say, 10 images per page averaging 100KB each (across all responsive sizes), and 1,200 visitors viewing 5 pages each, that's: 1,200 × 5 × 10 × 100KB = 6GB. That could explain high usage.
Potential Solutions
- Limit responsive image sizes: Configure
gatsby-imageto generate fewer size variations - Use consistent transformation parameters: Make sure your image queries are consistent across builds
- Consider using
gatsby-plugin-sanity-image: This is a more modern alternative that might handle caching better than the oldergatsby-source-sanity+gatsby-imagecombo - Optimize image quality settings: You mentioned trying this, but finding the sweet spot between quality and file size is key
The bandwidth you're seeing is likely legitimate traffic, not a caching problem with Sanity's CDN itself. The CDN is doing its job correctly - the issue is probably the volume of image variants being served and the number of requests per visitor.
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.