CDN & Edge Media Delivery

Pushing image transformation out to the edge changes the economics of media delivery. Instead of pre-generating every format and every width at build time and shipping the whole matrix to your origin, you store one high-quality master and let the edge derive AVIF, WebP, and the exact pixel dimensions each viewport needs — cached the first time and served from memory forever after. Done well, this collapses origin egress, shortens the critical path to the Largest Contentful Paint image, and lets a single URL serve the right bytes to a Safari 14 phone and a Chrome 121 desktop at the same time. Done badly, it poisons caches, doubles origin fetches, and serves an undecodable AVIF to the exact clients least able to recover. This section covers the theory and the platform-specific mechanics that separate the two outcomes.

The hard problems at the edge are not “how do I resize a JPEG.” They are: how does a shared cache decide which stored variant answers a given request, how do you keep that decision from fragmenting your hit rate into uselessness, and how do you insulate your origin from the transformation load when a cold cache stampedes it. Every platform below solves those three problems differently, and the differences are exactly where production incidents come from.

What this section covers

The topics below build from the general negotiation model down to per-platform configuration and the monitoring that keeps a working setup from silently regressing. Each area has its own dedicated pages.

Cloudflare Image Resizing and Polish — the /cdn-cgi/image/ transformation URL, Workers-based cf.image resizing, and Polish’s zero-config automatic WebP/AVIF re-encoding. When each applies, how they bill, and how to debug what actually reached the browser.

AWS CloudFront Cache Behaviors for Media — cache policies that include Accept in the cache key, CloudFront Functions versus Lambda@Edge for format routing, and diagnosing the cache misses that quietly send every request to your origin.

Fastly VCL for Image Format Negotiation — normalizing req.http.Accept in vcl_recv to a small set of cache variants, driving the Fastly Image Optimizer, and using shielding to concentrate transformation work on a single POP.

Monitoring & Regression for Media Delivery — enforcing image-weight budgets in Lighthouse CI, diffing WebPageTest filmstrips for LCP regressions, and tracking p75 LCP field data through the CrUX API so a bad deploy shows up before your users report it.

Edge delivery overview

The diagram traces one image request from the master asset on your origin through the edge transformation and cache layer to the browser. The cache-key box is the pivot point: everything upstream produces bytes, everything downstream consumes them, and the key decides whether a request is answered from edge memory or forwarded to origin.

Core theory: transforming and negotiating at the edge

Edge image transformation

Edge transformation moves the decode-resize-re-encode pipeline from your build step (or origin server) into the CDN’s compute layer, executed the first time a given variant is requested. A request for a 640-pixel-wide AVIF derived from a 4000-pixel master causes the edge to fetch the master once, run it through a resize and an AVIF encoder, cache the result, and return it. Every later request for that same variant is a pure cache read.

This inverts the classic build-time model. With build-time generation you decide up front which widths and formats exist; anything you did not pre-generate 404s or serves an oversized fallback. With edge transformation the set of variants is open-ended — any width in the option string is valid — but you pay a one-time encode cost per unique variant and you must bound that set deliberately, because an unbounded set (arbitrary width values from client-side JavaScript, for example) turns every request into a cache miss and a fresh encode.

Tradeoff: on-the-fly AVIF is CPU-expensive. A single 1600-pixel AVIF encode is tens to low hundreds of milliseconds of edge compute. That cost is invisible on a warm cache and brutal on a cold one. The mitigation is a constrained, enumerable variant set plus origin shielding, both covered below.

What a transform actually costs

The encode is not the only cost, and knowing the shape of each stage tells you where to spend effort. On a single edge core, a 4000 × 3000 JPEG master decodes in roughly 40–70 ms; a Lanczos downscale to 1600 px adds another 10–20 ms; and the re-encode dominates everything else — on the order of 120–260 ms for AVIF at encoder speed 6, 25–45 ms for WebP at method 4, and 8–15 ms for a baseline MozJPEG. Raising the AVIF speed setting to 8 roughly halves the encode but gives up several percent of file size at matched quality, which is the compression/CPU curve catalogued in AVIF vs WebP compression benchmarks.

The whole of that cost lands on exactly one request per variant: the unlucky first viewer, whose time-to-first-byte absorbs decode plus resize plus encode before a single byte of image is sent. Three mitigations belong in the design from the start:

• Request coalescing. If a hundred viewers hit the same cold variant within the encode window, a naive edge runs a hundred encodes. Cloudflare, Fastly, and a correctly configured CloudFront Origin Shield collapse concurrent misses for the same key into one upstream request; the rest wait on that single in-flight fetch. Verify this is actually on — it is the difference between one encode and a self-inflicted denial of service on a viral asset.
• Serve stale while you re-encode. Emitting stale-while-revalidate on transformed responses lets the edge answer instantly from the previous variant while the refresh runs in the background, so a TTL expiry never becomes a latency cliff. The semantics and the exact directive combinations are covered in stale-while-revalidate for media assets.
• Pre-warm what matters. For the handful of URLs that are LCP candidates on high-traffic templates, fire a build-time or post-deploy curl loop over each (width, format) pair against a shielded POP. Twenty requests at deploy time removes the cold-encode penalty from the one image the Largest Contentful Paint depends on.

A fourth option — do not transform at the edge at all for the small, stable, above-the-fold set — is legitimate and underused. Pre-generate the hero variants at build time, ship them as content-hashed objects, and let the edge transform only the rarely-requested tail of gallery and article imagery where pre-generation would be wasteful.

Accept-based negotiation at the edge

Browsers advertise decodable image formats in the Accept request header. Chrome 121 sends image/avif,image/webp,image/apng,*/*;q=0.8; Safari 14 sends image/webp,image/*,*/* (no AVIF); an ancient client sends only */*. Edge negotiation reads this header and picks the best format the client can actually decode — AVIF if present, else WebP, else the JPEG master — from a single canonical URL. The browser never has to author a <picture> fallback chain for format, because the edge already served the right bytes.

This is strictly more robust than static <picture> negotiation for format selection, because the decision is made against the live Accept header rather than a hard-coded type gate. It does not replace <picture>/srcset for resolution selection — the browser still chooses which width to request based on sizes and the display — but it removes the need to physically store an AVIF and a WebP copy of every asset. The format axis collapses into one URL. This is the same negotiation contract described for origin servers in Cache-Control Headers for Image and Video Assets, pushed one hop closer to the user.

Reading Accept without getting it wrong

Accept is a comma-separated list of media ranges with optional quality weights, defined in RFC 9110 §12.5.1. The obvious implementation — parse the ranges, sort by q, take the highest-weighted range the transformer can produce — is wrong, and it fails in the one direction that hurts: it serves AVIF to browsers that cannot decode it.

The reason is wildcards. Safari 14 sends image/webp,image/*,*/*;q=0.8. The image/* range has an implicit weight of 1.0 and matches image/avif under the media-range matching rules, so a q-ranking parser concludes the client happily accepts AVIF. It does not: a wildcard range advertises willingness to receive a media type, never the ability to decode a specific codec. The same trap catches */* on its own, which every curl invocation and most crawlers send.

The correct rule is a strict, ordered test for explicit subtype tokens, with no wildcard participation at all:

1. If the header literally contains image/avif, serve AVIF.
2. Otherwise, if it literally contains image/webp, serve WebP.
3. Otherwise serve the JPEG or PNG baseline — including when the header is */*, image/*, empty, or absent entirely.

Two further edge cases bite in production. First, an explicit zero weight is a refusal: image/avif;q=0 means “do not send me AVIF”, and a substring test for image/avif will happily ignore that. Chrome does not currently emit it, but a corporate proxy or a hardened client can, so the strict token test should reject a token whose parameters include q=0. Second, an intermediate proxy that rewrites or strips Accept collapses every client into the baseline tier; if you see 100 % JPEG traffic from one ASN, suspect header stripping before you suspect the transformer.

Client hints are the modern alternative axis — Sec-CH-DPR and Sec-CH-Width let the edge pick a resolution without the URL carrying one — but there is no client hint for format support, so Accept remains the only signal for the format decision. Treat the two as orthogonal: Accept selects the codec, srcset/sizes or client hints select the pixel count, as laid out in mastering srcset and sizes for responsive layouts.

Cache-key design

A cache is a map from key to bytes. For negotiated media the key must encode everything that changes the response: the base URL, the transformation options (width, quality, fit), and enough of the Accept header to distinguish AVIF-capable clients from WebP-only ones — but no more than that. The design failure that fragments hit rates is keying on the raw Accept string. Chrome, Firefox, Safari, and every crawler send subtly different Accept values (different q weights, different */* orderings), so a raw-Accept key produces a distinct cache entry per user-agent family for the exact same image. Hit rate collapses; origin load and encode cost explode.

The fix is normalization: collapse the infinite space of real Accept strings into a tiny enumerated set — avif, webp, or jpeg — and key on that token instead. Fastly does this with a req.http.Accept rewrite in vcl_recv; Cloudflare does it internally for Polish and Image Resizing; CloudFront does it with a cache policy that either includes Accept (and relies on you normalizing upstream) or, more robustly, with a function that maps Accept to a small custom header used in the key.

Variant cardinality and the hit-rate arithmetic

Cache-key design is not a matter of taste; it is arithmetic you can do before you deploy. The number of distinct objects a single master image occupies at a single POP is the product of every dimension in the key:

objects = |formats| × |widths| × |quality values| × |everything else you accidentally keyed on|

Every one of those objects needs its own cold miss to become warm, and every cold miss for a transforming edge is a fresh encode. A POP holds a finite working set with an LRU eviction policy, so multiplying the object count does not merely delay warmth — past a threshold it guarantees that objects are evicted before they are requested a second time, and the hit rate stops recovering at all.

Work a concrete model. Take one master image, one POP that receives 2,400 requests a day for it, and a 24-hour TTL. Requests are spread across the object set roughly uniformly, so the expected number of misses over the day is N × (1 − e^(−R/N)) for N objects and R requests. In production, browsers emit around 120 distinct raw Accept strings across versions and platforms, and unclamped client-side width values settle at roughly 15 distinct values once device pixel ratios and layout breakpoints multiply out. That gives four candidate designs:

Two lessons fall out of the table. The first is that normalizing Accept is worth more than clamping widths: collapsing 120 strings to 3 tokens moves the hit rate 23 points further than trimming 15 widths to 5. The second is that the two fixes are not alternatives. Leaving either axis unbounded leaves you one careless change — a new ?dpr= parameter, a marketing ?utm_source that slips into the key — from multiplying the object count again. Enumerate both axes explicitly and reject anything outside the enumeration with a 400 rather than silently encoding it.

Warning: the arithmetic above is per POP. A global CDN with 42 POPs multiplies the cold-miss count by 42 unless a shielding tier absorbs them, which is why the shielding discussion below is not an optional optimization but part of the same calculation.

Vary: Accept versus a normalized cache key

There are two correct ways to make a shared cache serve the right format, and mixing them up is a classic incident:

• Vary: Accept tells every downstream RFC-9111 cache (the CDN, corporate proxies, the browser cache) to store a separate object per distinct Accept value. It is honest and standards-compliant, but because Accept values vary wildly between clients, a literal Vary: Accept can itself shatter the cache unless the CDN normalizes Accept before applying it.
• A normalized cache key keeps the key internal to the CDN: the edge computes avif|webp|jpeg from Accept, keys on that, and typically emits a stable representation to downstream caches. This is what Cloudflare does automatically and what a well-written Fastly VCL does explicitly.

Warning: emitting Vary: Accept while also letting a downstream CDN key on the raw header double-fragments the cache — once for the header value and once for the internal token. Pick one model per hop. The rule of thumb: normalize Accept to a token as early as possible, key on the token, and only emit Vary: Accept to caches you do not control (the browser and intermediary proxies) so they at least do not serve an AVIF to a WebP-only client.

Three consequences of Vary are easy to miss until they cause an incident:

• Revalidation carries the Vary set too. When a stored variant goes stale, an RFC-9111 cache issues a conditional request and must present the same selecting header values it originally stored. If a client’s Accept has drifted between the original request and the revalidation — a browser update is enough — the cache cannot match the stored variant and falls back to a full fetch. Long immutable lifetimes on content-hashed URLs sidestep this entirely, because nothing ever revalidates.
• Vary: * is a caching veto. Some frameworks emit it defensively. It means “this response is uncacheable by any shared cache”, and applied to media it takes your entire image tier off the edge. Grep for it before blaming the CDN.
• Vary does not protect against a wrong Content-Type. It only tells a cache which requests may reuse a stored response. If the transformer labelled an AVIF payload image/jpeg, Vary will faithfully serve that mislabelled object to everyone in the same variant bucket. Content-type correctness is a separate contract, covered in MIME type configuration for modern media servers.

The practical policy for a negotiated media tier is therefore: normalize at the outermost hop you control, key internally on the token, emit Vary: Accept on the response so the browser cache and any corporate proxy stay honest, and give every transformed object a Cache-Control lifetime long enough that revalidation is rare.

Shielding and origin offload

A CDN has dozens or hundreds of edge POPs, each with its own cache. On a cold deploy, a popular image can miss simultaneously at every POP, and every POP independently fetches the master from your origin — a thundering herd that can saturate origin bandwidth exactly when traffic is highest. Shielding (Fastly’s term; Cloudflare calls the analogous mechanic Tiered Cache / Argo, CloudFront calls it Origin Shield) designates one intermediate POP that all other POPs consult before reaching origin. Origin then sees at most one fetch per variant instead of one per POP. For edge transformation this matters doubly: the shield POP also concentrates the expensive encode, so a variant is transformed once globally rather than once per region.

Choosing the shield location is a latency decision, not a throughput one. Put the shield in the region closest to origin: a miss now costs the viewer one extra edge-to-shield hop, and you want that hop to be the short one. Placing a European shield in front of a us-east-1 origin adds a transatlantic round trip to every miss served in Asia. Most platforms expose the shield as a per-origin setting, so a distribution with a US object store and a European API can shield each independently.

Tradeoff: shielding converts a wide, shallow failure into a narrow, deep one. When the shield POP has a bad minute, every POP behind it is affected simultaneously, whereas an unshielded fleet degrades one region at a time. Platforms mitigate this with automatic failover to a secondary shield or a direct-to-origin path, but the operational consequence is real: shield health belongs on the same dashboard as origin health, and the alert threshold should be tighter than for any single edge POP.

There is a second, quieter benefit worth designing around. Because the shield holds a superset of what any single POP holds, its hit rate for the rarely-requested tail of rarely-requested gallery images is far higher than the edge’s. For a catalogue where most assets are requested a handful of times per day globally, the shield is where the cache actually lives; the edge tier only serves the head of the distribution. That changes what you measure — a mediocre edge hit rate with an excellent shield hit rate is a healthy system, not a broken one, and monitoring that reports only the edge number will mislead you.

Platform capability reference

The table compares how the three major CDNs handle the four capabilities that decide a media architecture. “Edge compute” is the mechanism you would use for custom routing logic beyond the built-in transformer.

Tradeoff: Cloudflare and Fastly ship a managed transformer, so you write configuration; CloudFront makes you assemble the transformer from Lambda@Edge, so you write and maintain code. The CloudFront path is more work but gives byte-level control over the encoder and its parameters — see Lambda@Edge AVIF conversion on CloudFront.

Canonical delivery pattern

The most portable canonical pattern is a transformation URL that carries the derivation intent in the path and lets the edge negotiate format from Accept. Cloudflare’s form is the clearest example:

<!--
  The /cdn-cgi/image/ prefix is intercepted by Cloudflare's edge before it
  ever reaches your origin. The options segment declares the derivation:
    width=640     target width in device pixels (bounds the variant set)
    quality=75    perceptual quality; 75 is a strong photographic default
    format=auto   negotiate AVIF/WebP/JPEG from the request Accept header
  The final segment is the ORIGIN path of the master image. One tag, and
  the edge serves AVIF to Chrome and WebP to Safari 14 from this single URL.
-->
<img
  src="/cdn-cgi/image/width=640,quality=75,format=auto/img/hero-master.jpg"
  srcset="/cdn-cgi/image/width=640,quality=75,format=auto/img/hero-master.jpg 640w,
          /cdn-cgi/image/width=1280,quality=75,format=auto/img/hero-master.jpg 1280w"
  sizes="(max-width: 700px) 100vw, 640px"
  width="640" height="400"
  alt="Product hero photographed on a neutral background"
  fetchpriority="high">

For CloudFront the canonical unit is not a URL prefix but a cache policy that admits Accept into the key so the negotiated variant is stored correctly:

// CloudFront cache policy (Terraform-style shape). Without Accept in the
// cache key, CloudFront strips it and caches whichever format was produced
// first — then serves that one format to every client. This is the single
// most common cause of "AVIF shows up in Safari 14" incidents on CloudFront.
{
  "Name": "media-accept-negotiation",
  "ParametersInCacheKeyAndForwardedToOrigin": {
    "HeadersConfig": {
      "HeaderBehavior": "whitelist",
      "Headers": { "Items": ["Accept"] } // normalize upstream to avoid fragmentation
    },
    "QueryStringsConfig": { "QueryStringBehavior": "whitelist",
      "QueryStrings": { "Items": ["width", "quality"] } },
    "CookiesConfig": { "CookieBehavior": "none" }
  }
}

Full walk-throughs live in CloudFront cache policy for Vary/Accept negotiation and, for the URL-parameter form, Configuring Cloudflare Image Resizing URL parameters.

Pipeline integration

Fastly: normalize then negotiate

Fastly runs your logic in VCL. The pattern is to collapse Accept to a token in vcl_recv so the cache keys on three values, not thousands:

sub vcl_recv {
  # Normalize the wildly-varying Accept header down to a single token.
  # This token — not the raw header — becomes part of the cache variant,
  # so Chrome, Firefox, and crawlers that all support AVIF share ONE entry.
  if (req.http.Accept ~ "image/avif") {
    set req.http.X-Format = "avif";
  } elsif (req.http.Accept ~ "image/webp") {
    set req.http.X-Format = "webp";
  } else {
    set req.http.X-Format = "jpeg";
  }
  # Shielding: funnel all POPs through one datacenter so origin and the
  # image transform each run once per variant globally, not once per POP.
  if (req.http.host && !req.http.Fastly-FF) {
    set req.backend = ssl_shield_bwi_va_us;
  }
}

The X-Format token then drives the Image Optimizer format and is included in the object variant. Details: Fastly VCL: normalize Accept header for AVIF.

Cloudflare Workers: programmatic resizing

When the built-in URL form is not expressive enough — conditional quality, signed URLs, per-route rules — a Worker calls fetch with cf.image options:

export default {
  async fetch(request) {
    const accept = request.headers.get('Accept') || '';
    // Choose the encoder format from the live Accept header. format:'auto'
    // also works; picking explicitly lets you gate AVIF behind a flag.
    const format = accept.includes('image/avif') ? 'avif'
                 : accept.includes('image/webp') ? 'webp'
                 : 'jpeg';
    const url = new URL(request.url);
    return fetch('https://origin.example.com' + url.pathname, {
      cf: {
        image: {
          width: 640,        // bound the variant set — never pass raw client input unclamped
          quality: 75,       // perceptual quality target
          format,            // negotiated above
          fit: 'scale-down', // never upscale past the master's intrinsic size
        },
        // Cache the transformed result at the edge for a year; the master is
        // content-hashed so a new deploy produces a new URL rather than a stale hit.
        cacheEverything: true,
        cacheTtl: 31536000,
      },
    });
  },
};

The full Workers and Polish setup is in Cloudflare Image Resizing and Polish.

Monitoring the pipeline

An edge media setup degrades silently: a cache policy change drops the hit rate, a quality bump inflates payloads, a format regression ships AVIF to WebP-only clients. Wire the pipeline to a budget so regressions fail a build rather than a user’s LCP — enforce image-weight assertions in Lighthouse CI budget enforcement for image weight and watch the p75 field trend in tracking LCP field data with the CrUX API.

Invalidating derived variants

Purging a transformed asset is harder than purging a static one, because the thing you want to remove is not the thing you uploaded. When a designer replaces hero-master.jpg, the stale bytes at the edge are not stored under /img/hero-master.jpg — they are stored under /cdn-cgi/image/width=640,quality=75,format=auto/img/hero-master.jpg and a dozen sibling option strings, each with its own negotiated format variant. Purging the master path clears the origin copy and leaves every derivative untouched.

There are three workable strategies, in increasing order of robustness:

1. Enumerate and purge the derivatives. Feasible only when the option set is small and known to your build. It is the approach that breaks first, because it silently misses any URL an engineer added by hand.
2. Purge by surrogate key or cache tag. Tag every derivative of a master with the master’s identifier at transform time (Surrogate-Key: img-hero-master on Fastly, Cache-Tag: on Cloudflare Enterprise), then purge the tag. One call removes all widths and all formats. This is the correct answer when your platform supports it and you can control response headers on the transformed object.
3. Never purge at all: content-hash the master path. If the master is hero.a3f9c2.jpg, then every derivative URL contains that hash, and replacing the image produces hero.b71e04.jpg — a completely disjoint key space. The old derivatives age out on their own TTL with no purge call, no propagation delay, and no quota. Paired with Cache-Control: max-age=31536000, immutable this is the production standard, and it is why best practices for setting max-age on CDN media assets treats hashing as a prerequisite for long lifetimes rather than an optimization.

Warning: a global “purge everything” during an incident throws away every warm derivative across the whole fleet. On a transforming edge that is not just a cache-fill event — it re-runs every encode, so a purge-all can cost more CPU in ten minutes than a normal week. Reach for tag-scoped purges, and treat purge-all as a break-glass action with the same review as a config rollback.

Locking down the transformation endpoint

An open transformation URL is an open image proxy. If /cdn-cgi/image/width=2000,quality=95/<any path> accepts an arbitrary origin path — or worse, an arbitrary remote URL — anyone can point it at their own assets, mint an unbounded number of cache-key variants, and bill the CPU to you. Two controls close it:

• Restrict the source. Only allow derivation from paths under your own asset prefix, and reject absolute URLs outright. Cloudflare Image Resizing restricts this to the zone by default; a hand-rolled Worker or Lambda@Edge does not, unless you write the check.
• Sign the option string. Append an HMAC of the path plus options, computed with a server-side secret, and have the edge reject any request whose signature does not match. Signing has the useful side effect of making the variant set literally unforgeable: only option strings your application generated will ever produce an encode.

Signing costs you the ability to hand-write a transformation URL in a template, so most teams generate them through a single helper function. That helper is a good place to also enforce the width allowlist, clamp quality to a sane band, and emit the srcset string, so the enumeration lives in exactly one file.

Tradeoffs & failure modes

Browser & CDN compatibility matrix

Format decode support is a browser property; the edge only decides which of these you send. The columns match the site-wide baseline.

Edge capability by platform

Frequently asked questions

Where to go next

Start with the platform you run. If you are on Cloudflare, the Image Resizing and Polish guide is the fastest path to a working negotiated pipeline. On AWS, begin with CloudFront cache behaviors for media and get the cache policy right before adding transformation. On Fastly, the VCL negotiation guide covers the normalize-then-transform pattern. Regardless of platform, wire up monitoring and regression detection before you trust the setup in production — an unmonitored edge pipeline is one deploy away from a silent LCP regression.

Related

• Cloudflare Image Resizing and Polish — /cdn-cgi/image/ transforms, Workers cf.image, and zero-config Polish
• AWS CloudFront Cache Behaviors for Media — cache policies, Lambda@Edge routing, and cache-miss diagnosis
• Fastly VCL for Image Format Negotiation — normalizing Accept and driving the Image Optimizer from VCL
• Monitoring & Regression for Media Delivery — Lighthouse CI budgets, WebPageTest diffs, and CrUX field tracking
• Cache-Control Headers for Image and Video Assets — the origin-side max-age, immutable, and Vary contract the edge builds on
• MIME Type Configuration for Modern Media Servers — correct Content-Type registration for AVIF and WebP masters