# Image delivery at the edge: resizing, formats, and the round trips you can skip

Source: https://edgecommercejournal.com/blog/2026-10-04-edge-image-resizing-formats.html

Oct 4, 2026 - Edge Commerce Journal


On a typical product page, images are the majority of the bytes. They are also the asset least suited to one-size-fits-all delivery: a phone on a slow connection and a desktop on fiber need very different versions of the same product photo. Edge image transformation solves this by generating the right variant at the network edge, close to the shopper, instead of forcing the origin or the build pipeline to pre-generate every combination.

## What edge image transformation actually does

The mechanism is a URL convention plus on-the-fly processing. Instead of linking to `/images/hoodie.jpg`, the storefront links to something like `/images/hoodie.jpg?width=640&format=avif`. The first time a variant is requested, the edge fetches the master image from the origin, resizes and re-encodes it, serves it to the shopper, and caches the result. The next request for the same variant is a cache hit. The origin only ever stores the master.

This collapses a combinatorial problem. A catalog with 10,000 products, six responsive breakpoints, and three formats would need 180,000 pre-generated files. With edge transformation, you store 10,000 masters and generate variants lazily, keeping only the ones shoppers actually request. Long-tail products that never get viewed on a 4K monitor never cost you the transformation or the storage.

## Format negotiation: the quietest win

The biggest payload savings usually come from format, not size. A product photo served as AVIF or WebP is often 30 to 50 percent smaller than the same photo as JPEG at equivalent visual quality. The edge can inspect the `Accept` header on each request and serve the best format the browser supports, without the storefront markup needing to know anything about it.

This matters because format support is fragmented. Older Safari versions do not decode AVIF, some in-app browsers lag on WebP, and email clients are their own story. Hard-coding one format in your markup forces a lowest-common-denominator choice. Letting the edge negotiate per request means every browser gets its best option, and the markup stays simple.

## Where it goes wrong: cache key sprawl

Every transformation parameter becomes part of the cache key, and sloppy URL conventions create an explosion of near-identical variants. A storefront that generates `?width=640` in one template, `?w=640` in another, and `?width=641` from a rounding bug in a third is storing three copies of the same image and paying three origin fetches. We have covered [cache key sprawl](2026-10-01-cache-key-sprawl-edge.md) before; images are where it hurts most because each variant is heavy.

The fix is discipline in the URL scheme. Canonicalize parameters (one name, one set of allowed widths), round to a fixed set of breakpoints instead of arbitrary pixel values, and make sure every template on the site uses the same helper to build image URLs. A small number of predictable variants is the whole point; an unbounded number defeats it.

## The origin still matters

Edge transformation does not fix a bad master image. If the origin stores a 6MB uncompressed TIFF as the source, the first transformation of each variant is slow and expensive, and that cost lands on the first shopper who requests it. Keep masters reasonably sized (a high-quality JPEG or a lossless original at the largest size you will ever need), strip metadata you do not need, and consider warming the cache for hero images on key pages after a deploy.

Also watch animated and transparent images. Transformation pipelines handle JPEG and PNG gracefully, but animated GIFs, APNG, and transparency in next-gen formats have sharp edges: some pipelines flatten transparency silently or drop animation frames. Test your actual catalog images, not just a sample, before rolling out format negotiation site-wide.

## How to tell if it is working

Measure bytes per page view by device class, not just aggregate transfer size. A working edge image pipeline shows a clear split: mobile sessions download far fewer image bytes than desktop sessions for the same pages. Check the `Age` and content-type headers on a few variant URLs to confirm the edge is serving cached transformations in the negotiated format. And audit your cache for variant counts per master image: if a single product photo has hundreds of variants, your URL scheme needs tightening before your storage bill tells you the same thing.

## Frequently asked questions

### Why resize images at the edge instead of the origin?

Resizing at the edge produces each variant once, near the shopper, and caches it, so the origin never repeats the work and later visitors get the cached size instantly. Origin resizing either pre generates every variant in advance or pays the processing cost on the first request for each size.

### Which image format should a storefront default to?

Modern formats like WebP and AVIF for browsers that support them, with the original format as fallback, delivered automatically by content negotiation. AVIF compresses hardest but encodes slowest, which is another argument for generating variants at the edge where they are cached.

### Do resized variants hurt image quality for shoppers?

Not when the variant is generated from the full size master at the requested dimensions. Quality suffers when a small variant is stretched up or when a platform re compresses an already compressed image. Serve a variant at or slightly above the display size and quality holds.

### How do image variants affect SEO?

Search engines index the images they can fetch, so variants must be reachable at stable URLs and referenced correctly in the page markup, including responsive source sets. Edge generated variants are fine for indexing as long as the URLs are consistent and not blocked from crawlers.