Image Delivery at the Edge: WebP, AVIF and Responsive Sizes

An image CDN should serve AVIF to the roughly 93–95% of browsers that decode it as of 2026, WebP to most of the rest, and JPEG as a last resort, at a width close to the rendered slot. Done naively, that means one source image fans out into thousands of cache objects and your hit ratio collapses. Done correctly, you normalize the Accept header to three format buckets and quantize widths to about nine steps. That caps every source at 27 variants, keeps edge hit ratios in the high 90s, and still cuts image bytes by 40–60% against unoptimized JPEG.

Why image CDN variants fragment the cache

Each transformation dimension multiplies the object count. Three dimensions matter: format, width, and device pixel ratio (DPR). Quality is sometimes a fourth. If width comes straight from a client hint or an unbounded URL parameter, a single hero image can realistically be requested at hundreds of distinct widths across a device fleet.

Raw Accept headers make it worse. Chromium, Safari, and Firefox each send different Accept strings for image requests, and those strings change between browser versions. Vary on the raw header and a mid-sized site sees dozens of distinct values for the same URL. Each value becomes a separate cache entry holding byte-identical content.

A worked model of variant count vs. hit ratio

Assume one image receives 10,000 requests per day at a given edge cache, and each distinct variant costs exactly one cold miss per TTL window. This is a simplified model, not a benchmark:

• Bounded: 9 widths × 3 formats = 27 variants. Worst-case cold misses are 27 of 10,000, a 0.27% miss contribution.
• Unbounded: 2,000 observed widths × 3 formats = 6,000 variants. Worst-case cold misses approach 60%, and most of those variants are never requested twice.

The long tail is what hurts. Every cold miss is a transform, and transforms are expensive. AVIF encoding commonly costs several times the CPU of an equivalent WebP encode at comparable speed presets, and can reach hundreds of milliseconds for large sources. A fragmented cache turns image optimization at the edge into a CPU cost center with p99 latency to match.

How WebP and AVIF delivery should negotiate at the edge

You have two viable designs. They carry different cache behavior.

Markup negotiation uses a picture element whose source entries declare type image/avif and image/webp, falling back to a plain JPEG. Each format gets its own URL, so no Vary header is needed and every cache in the path behaves predictably. The cost is heavier HTML, plus a template change for every image slot.

Header negotiation keeps one URL and has the edge choose the format from the Accept header. Templates stay simple. The CDN must normalize the header into its cache key, and it must emit Vary: Accept so downstream caches and browsers do not cross-serve formats.

For most teams, header negotiation with strict normalization is the better default, because it works on legacy markup and third-party embeds. Use markup negotiation when you do not control the cache key logic of every layer in front of users.

Edge cache key rules for responsive images

The key insight from these rules: everything the client sends is folded into two small enumerations, format and width step, before it can reach the cache key.

Put width in the path, for example a w640 segment ahead of the filename, rather than in a query parameter. Some cache layers ignore or reorder query strings. Make the srcset w descriptors in your templates list exactly the nine allowed widths, so browsers request only widths that already exist in cache. A sizes attribute that reflects the real layout matters as much as the formats themselves.

Client hints such as Sec-CH-Width and Sec-CH-DPR remain Chromium-only in 2026 and require an Accept-CH opt-in. Treat them as an optimization for one engine family, not as the primary width signal.

As of 2026, AVIF is decodable in roughly 93–95% of browsers in global use, including Chrome, Firefox, and Safari 16 and later, and typically produces files 20–30% smaller than WebP at matched perceptual quality. An image CDN that normalizes the Accept header to three format buckets and quantizes widths to nine steps caps each source image at 27 cached variants, compared with thousands under free-form resizing.

Trade-offs and failure modes of image optimization at the edge

• Missing Vary: Accept. If the edge normalizes correctly but omits Vary, a corporate proxy or shared browser cache can hand AVIF bytes to a client that cannot decode them. The result is a broken image with no server-side error.
• Quality scales are not portable. AVIF quality 50 is not JPEG quality 50. Tune each format against a perceptual metric such as SSIMULACRA2 or Butteraugli. AVIF at aggressive settings smears fine texture like fabric and foliage, and dashboards will not show it.
• First-request latency. A cold AVIF variant can add hundreds of milliseconds. Tier the cache behind an origin shield so each variant is encoded once globally, not once per edge.
• Extension mismatch. Serving WebP bytes under a .jpg path is valid HTTP, but users who save the file get confusing results. Always set an accurate Content-Type.
• Storage pressure. Even 27 variants per image can multiply the working set by 5–10x in bytes. Your cache must hold the hot set or hit ratio erodes from eviction instead of fragmentation.

That last point is where storage hardware matters. BlazingCDN runs its edge on NVMe SSD storage with flexible configuration, which helps keep a multiplied variant set resident instead of evicted; its edge caching and image delivery features are worth checking against your variant budget.

Verify this on your own stack

• Request one image with a Chromium Accept header and again with a JPEG-only Accept header. Confirm Content-Type differs and both responses carry Vary: Accept.
• Group edge logs by path without format or width, then count distinct cache keys per source. Anything above about 30 means normalization is leaking.
• Split cache hit ratio for image paths from everything else. Image hit ratio below 95% on a stable catalog usually signals fragmentation, not TTLs.

Who this design fits

This design fits catalogs with thousands to millions of images, such as ecommerce, media, and user-generated content, where traffic concentrates on a hot set and transform CPU is a real line item. It fits less well for small marketing sites with a few dozen images. There, pre-generating AVIF and WebP at build time and using markup negotiation is simpler, and it needs no edge logic at all.

Run the variant audit this week

Pull 24 hours of edge logs for image paths and compute distinct cache keys per source image. Then compare the image hit ratio to your overall hit ratio. If keys per image exceed 30, or image hit ratio trails the site average by more than 3 points, adopt the three-bucket Accept rule and the nine-width allow-list, align your srcset to those widths, and re-measure after one full TTL cycle. Track transform CPU seconds and image bytes per page view before and after. Those two numbers will tell you whether AVIF is paying for itself on your traffic.