Image Optimization at the Edge

The transform pipeline

An incoming image request typically passes through a fixed sequence of transforms at the edge:

1. Parse parameters — width, height, quality, format, fit mode (cover/contain), gravity (where to crop), DPR (device pixel ratio).
2. Negotiate format — pick the best output format the client's Accept header advertises support for.
3. Fetch source — pull the master image from origin (or a cached copy of the master) if no variant cache entry exists.
4. Decode — into a raw pixel buffer.
5. Resize — to the requested dimensions, with the requested fit/gravity behavior.
6. Re-encode — into the negotiated output format at the requested quality.
7. Cache + serve — store the variant at the edge and return it with appropriate Cache-Control and Vary headers.

Every subsequent request for the same variant hits the edge cache directly, skipping every step after parameter parsing.

Format negotiation via Accept

The Accept header is how browsers signal which image formats they can decode. A modern Chromium browser sends something like:

Accept: image/avif,image/webp,image/apng,image/svg+xml,image/*;q=0.8,*/*;q=0.5

The CDN parses this list (which is ordered by preference) and picks the first format it can produce. For a JPEG source, the typical fallback chain is:

The response carries Vary: Accept so caches store one variant per format. See cache key and Vary for the variant-explosion implications.

Resizing parameters and their conventions

Edge image services have converged on a similar URL-parameter vocabulary:

Each unique combination is a separate cache entry. Limit the set of valid values (whitelisted widths, fixed quality tiers) to keep variant count bounded.

Responsive images via srcset

The HTML side of edge image optimization is the srcset attribute:

<img
  srcset="https://cdn.example.com/hero.jpg?w=400 400w,
          https://cdn.example.com/hero.jpg?w=800 800w,
          https://cdn.example.com/hero.jpg?w=1600 1600w"
  sizes="(max-width: 600px) 100vw, 50vw"
  src="https://cdn.example.com/hero.jpg?w=800"
  alt="Hero">

The browser picks the right width based on layout and device pixel ratio, fetches that URL, and the CDN returns the correct variant. The browser does no client-side resizing — the edge handles it.

For art-directed responsive images (different crops at different breakpoints), use the <picture> element with explicit sources per breakpoint.

Quality tuning and SSIM

Output quality is the most overlooked parameter. The default of "quality 85" exists because it produced acceptable JPEGs for early-2000s digital photography; for the modern web with AVIF, much lower values produce smaller files at indistinguishable quality.

Modern CDNs offer perceptual quality modes (SSIM-targeted or similar) that aim for a constant perceived quality across an image set rather than a constant encoder quality. The bandwidth savings vs fixed-quality at the same perceived quality are typically 10-25%.

Smart cropping and gravity

When resizing to a different aspect ratio than the source, the CDN has to decide what to crop. The options:

• Fixed gravity — center, top, bottom, left, right. Deterministic, simple, often wrong (decapitated portraits).
• Saliency-based — compute a saliency map and crop to retain the most visually important region. Generally good for product photography and landscapes.
• Face detection — explicitly detect faces and retain them. Right for portraits, social avatars, e-commerce people-shots.
• Manual focal point — origin annotates each image with an x,y focal point; the CDN crops around it. Best results but requires editorial workflow.

Caching strategy for derived variants

Two-tier caching pays off enormously for derived images. The variants are produced from masters; the masters change rarely; the variants are expensive to compute but cheap to store.

1. Origin — holds masters only. Long TTL (months).
2. Tier-1 edge / shield — caches recently-fetched masters and recently-produced variants. Long TTL.
3. Tier-2 edge POPs — caches the variants users in their region have requested. Long TTL.

If a tier-2 POP needs a variant it doesn't have, it asks the tier-1 shield. If the shield has the master cached, the variant can be produced without touching origin. Origin only ever serves master images, and only on cold-master misses.

Common pitfalls

• Unbounded dimensions — accepting ?w=999999 lets clients balloon the cache and origin compute. Whitelist allowed widths (e.g., 320, 480, 640, 800, 1024, 1600, 2400).
• Skipping Vary: Accept — without it, a WebP variant cached for a WebP-capable client gets served to a no-WebP client and breaks.
• Re-encoding losslessly-compressed sources — PNG icons re-encoded as JPEG get larger, not smaller, because of chroma subsampling. Always treat PNG/SVG specially.
• Stripping EXIF orientation — some encoders apply rotation; others don't. Force orientation normalization on resize.
• Animated GIFs — converting to WebP/AVIF animation works; treating them as static frames does not. Detect animation explicitly.

Browser-side image hints

Some browsers send additional client hints that the edge can use:

• Save-Data: on — the user has enabled a data-saver mode. Serve lower quality or smaller dimensions.
• Sec-CH-DPR, Sec-CH-Width — device pixel ratio and resource width. Allows the edge to serve a perfectly sized image without the markup carrying explicit width parameters.
• Sec-CH-Viewport-Width — viewport width in CSS pixels.

These require explicit opt-in via Accept-CH response headers. They are an additional Vary axis if used — plan cache-key implications.

Frequently Asked Questions

What is image optimization at the edge?

It is the practice of resizing, re-encoding, and reformatting images at the CDN edge rather than at the origin. The origin stores one high-resolution master per image; the CDN derives every served variant — different sizes, formats (WebP, AVIF, JPEG), and quality levels — on the fly and caches each variant at the edge. Clients always get an image format and size optimized for their device and browser.

How does the CDN know which image format to serve?

Through the Accept request header. Browsers list the image formats they can decode — for example, Accept: image/avif, image/webp, image/*. The CDN picks the most efficient format the client supports and re-encodes the source into it. The response includes Vary: Accept so the cache stores one variant per format the edge has produced.

What is the difference between WebP, AVIF, and JPEG XL?

All three are modern image formats with better compression than JPEG or PNG. WebP, from Google, is supported by every modern browser and gives roughly 25-35% smaller files than JPEG at equivalent quality. AVIF, based on AV1, gives roughly 50% smaller files than JPEG and has near-universal browser support today. JPEG XL is technically the most advanced format but has limited browser support. For most production use, AVIF is the target and WebP is the fallback for older clients.

Should I cache resized images at the edge or at the origin?

At the edge. Resizing on the origin requires precomputing every size you might serve, which wastes storage for variants that are rarely requested. Edge resizing computes variants only when first requested, caches the result, and serves it for the rest of its TTL. Origin only ever stores the master.

How does cache hit ratio look with image optimization?

Lower than for static images because the cache stores one variant per (URL, width, format, quality) combination. A single source image can produce 10-50 cache entries across all the resize/format combinations. This is acceptable because each variant is much smaller than the master and hit rate per variant is still high on popular images. Configure the CDN to limit the set of allowed dimensions to avoid unbounded variant explosion from malicious or buggy clients.