Slow TTFB for Sanity CDN images with new query param transformations
@sanity/image-urlto generate query param transformations. One observation is that when one or more query param changes value, the request takes quite some time where TTFB is pretty much all of the wait time.• Is anyone else experiencing this?
• Does it just take that long to generate a new version of an image server side maybe?
• Is there something that can be optimized in our transformations query params?
Example image url we have:
https://cdn.sanity.io/images/ <project-id>/<dataset>/<some-img>.png?rect=750,0,1406,1438&w=1112&h=1137&auto=format
After the initial long running request, requests for the same image with the same params are quick.
This is completely normal behavior you're experiencing! The slow TTFB on the first request is due to how Sanity's Image Pipeline works with on-demand transformations.
What's happening
When you request an image with new transformation parameters (like changing w=, h=, or rect=), Sanity's CDN needs to:
- Generate the transformation - The image is processed on-demand on the backend servers
- Cache the result - Once processed, it's cached on the CDN edge servers near your users
- Serve subsequent requests - Future requests for that exact URL are served instantly from cache
This is why your first request is slow (processing time) but subsequent requests are fast (served from cache). The Asset CDN caches transformed images indefinitely, up to 10 MB in size.
Common causes of cache misses
Every unique combination of parameters creates a new cache entry. So these would all be separate cache entries:
?w=1112&h=1137&auto=format?w=1113&h=1137&auto=format(just 1px different!)?rect=750,0,1406,1438&w=1112&h=1137&auto=format
Optimization strategies
1. Standardize your image sizes Instead of generating arbitrary widths, use a consistent set of breakpoints (e.g., 640, 768, 1024, 1280, 1920). This increases cache hit rates across your site.
2. Pre-warm critical images For above-the-fold or hero images, you can "pre-warm" the cache by making requests to the transformed URLs during your build process or via a script.
3. Consider the auto=format impact
The auto=format parameter uses the Vary: Accept header, meaning different browsers requesting different formats (WebP, AVIF, JPEG) create separate cache entries. This is usually worth it for the file size savings, but be aware of the tradeoff.
4. Round transformation values When calculating dimensions dynamically, round to consistent intervals rather than pixel-perfect values to improve cache reuse.
5. Avoid unnecessary rect parameters
If you're not actually cropping differently, don't include the rect parameter - it creates additional cache variations.
Is this a problem?
For most sites, this is fine because:
- First-time visitors experience the slow load once per image variant
- The CDN is built on Google's global infrastructure with good processing speed
- Cached responses are served from edge locations near your users
- The content-addressable URLs (with SHA-1 hashes) mean you never worry about stale caches
If you're seeing consistently slow transformations (multiple seconds), that could indicate very large source images that need processing. Consider uploading images at more reasonable source dimensions if they're extremely large.
Show original thread1 reply
Was this answer helpful?
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.
