Sanity CDN Bandwidth Usage High for Gatsby Site with gatsby-sanity-source

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:

1. 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.

2. Multiple image sizes: gatsby-image typically 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.

3. Auto-format parameters: If you're using auto=format in your image URLs, the CDN might be serving different formats (WebP, JPEG, PNG) to different browsers, which would count as separate requests.

4. 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

1. 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?

2. Monitor your CDN requests: Use your browser's Network tab to see what's actually being requested. Check the response headers for cache-control and whether requests are returning 304 (cached) or 200 (fresh download).

3. 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-image to 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 older gatsby-source-sanity + gatsby-image combo
• 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.