Hey! We're fetching responsive images from <http://cdn.sanity.io|cdn.sanity.io> using `@sanity/image-url` to generate query param transformations. One observation is that...

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:

1. Generate the transformation - The image is processed on-demand on the backend servers
2. Cache the result - Once processed, it's cached on the CDN edge servers near your users
3. 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.