CDN image optimization involves more than converting every JPEG to WebP or AVIF. A reliable implementation must coordinate dimensions, encoding quality, format fallbacks, content negotiation, cache keys, cache lifetimes, and origin protection. Otherwise, a modern browser may receive an older format, an incompatible client may receive AVIF, or the CDN cache may fragment into too many low-value variants.
As a general rule, reduce unnecessary pixels before changing the codec. AVIF often offers strong compression potential, while WebP provides broad modern-browser support and typically lower operational complexity. JPEG, PNG, GIF, or SVG may still be appropriate for particular content and fallback requirements. Make the final decision using representative images, target-browser data, visual quality, and encoding cost—not one quality value applied to every asset.
What Should CDN Image Optimization Accomplish?
The objective is to deliver enough image data for an acceptable visual result without sending unnecessary bytes. A complete workflow usually includes:
Generating widths and pixel densities that match the page layout.
Selecting lossy or lossless compression according to the content.
Choosing AVIF, WebP, or a fallback according to browser support.
Caching the final variants at the CDN so they are not re-encoded for every request.
Monitoring transfer size, cache-hit ratio, LCP, conversion latency, and errors.
A modern format cannot compensate for incorrect dimensions. A 3,000-pixel-wide AVIF displayed inside a 360-pixel mobile card may still waste more data than a correctly sized WebP or JPEG.
Choosing Between WebP, AVIF, JPEG, PNG, and SVG
| Format | Main Strength | Important Considerations | Typical Uses |
|---|---|---|---|
| AVIF | Often delivers high compression efficiency and supports lossy, lossless, transparency, and HDR features | Encoding can be computationally expensive; results vary by image and encoder | Photos, large hero images, and bandwidth-sensitive pages |
| WebP | Broad support in modern browsers, with lossy, lossless, transparency, and animation capabilities | It is not automatically smaller than a well-encoded AVIF or original format | General web images, photos, transparent graphics, and a modern fallback layer |
| JPEG | Mature compatibility and a widely available photo workflow | No transparency; usually less efficient than modern formats at similar visual quality | Photo fallback, legacy systems, and download compatibility |
| PNG | Reliable lossless output and transparency with sharp edges | Usually too large for photographic content | Screenshots, UI graphics, and assets requiring lossless detail or transparency |
| SVG | Scales without raster quality loss and can be compact for simple artwork | Unsuitable for ordinary photos; scripts and external resources require security controls | Icons, logos, diagrams, and geometric illustrations |
Do not turn “AVIF is always smaller than WebP” into a production rule. Photos, screenshots, transparent artwork, illustrations, and text-heavy graphics behave differently. Test representative assets at comparable perceived quality, then inspect gradients, sharp edges, skin tones, color accuracy, and transparency.
Should You Use picture and srcset or Accept Negotiation?
Both approaches can work, but they create different caching and operational models.
Option 1: List Formats Explicitly in HTML
<picture> <source type="image/avif" srcset="/images/hero-700.avif 700w, /images/hero-1400.avif 1400w"> <source type="image/webp" srcset="/images/hero-700.webp 700w, /images/hero-1400.webp 1400w"> <img src="/images/hero-700.jpg" srcset="/images/hero-700.jpg 700w, /images/hero-1400.jpg 1400w" sizes="(max-width: 700px) 100vw, 700px" width="700" height="394" alt="Example image"> </picture>
Each format and size has a separate URL, making CDN behavior easy to understand. The browser chooses a supported format and an appropriate candidate. This model is particularly suitable when variants can be generated during build or upload and is often simpler to troubleshoot on static sites.
Option 2: Return Different Formats from One URL
Browsers commonly list supported image MIME types in the Accept request header. An origin or edge function can prefer AVIF, then WebP, and otherwise return JPEG or PNG.
Request: GET /images/hero Accept: image/avif,image/webp,image/png,image/*;q=0.8,*/*;q=0.5 Response: Content-Type: image/avif Vary: Accept
When one URL can produce multiple representations, the cache must understand the selection input. Vary: Accept indicates that the response can change with the request's Accept value. On a CDN such as CloudFront, however, returning Vary from the origin does not by itself guarantee the desired cache-key design. The necessary request information must also be forwarded and included through an appropriate cache policy.
Why Not Put the Complete Accept Header in the Cache Key?
CloudFront does not vary objects on arbitrary headers by default. When a request header is included in a cache policy, its full value participates in the cache key. Browsers and versions may send different type lists, ordering, or quality values even when they should ultimately receive the same WebP file. Using every raw value can create redundant variants, reduce the cache-hit ratio, and increase origin traffic.
A more controlled approach is to normalize the complex header into a small set of capabilities at the viewer-request stage:
avifwhen the header includesimage/avif.webpwhen AVIF is unavailable butimage/webpis present.fallbackfor JPEG or PNG in other cases.
The normalized result can be represented by a controlled header or rewritten path, with the cache key varying only on those finite categories. This preserves compatibility without fragmenting the cache around many equivalent header strings.
Important: Test any CloudFront Function, Lambda@Edge function, or origin code that rewrites paths or selects formats on a non-production distribution first. A faulty cache key can store one format and serve it to clients that cannot decode it.
Image Dimensions Belong in the Variant Strategy
Format negotiation without dimension control rarely provides the best result. A site might generate a limited set of widths such as 320, 640, 960, 1280, and 1920 pixels, then use srcset and sizes to let the browser choose. Derive the actual breakpoints from layout widths and device data rather than copying a generic list.
If a dynamic image service accepts query parameters such as:
/image/product-123?width=640&quality=75&format=webp
Restrict the permitted values. Allowing arbitrary widths, qualities, and crops creates an effectively unlimited number of cache variants that can be abused or generated accidentally. Useful controls include:
Round requested widths to predefined buckets rather than accepting every integer.
Enforce minimum and maximum dimensions.
Allow only supported formats, crop modes, and quality ranges.
Normalize query-parameter order and default values.
Set conversion timeouts, concurrency limits, and output-size limits.
Generate Images in Advance or Transform on Demand?
| Method | Advantages | Costs and Risks |
|---|---|---|
| Generate during build or upload | Predictable behavior, no conversion delay on the first request, and straightforward testing and rollback | More storage and a workflow for creating and deleting variants |
| Generate on the first request and cache | Creates only variants that are actually requested and supports flexible applications | Slower first request and a need to prevent request storms, duplicate conversion, and parameter abuse |
| Managed image CDN or service | Quick access to resizing, cropping, format selection, and caching | Cost, platform limits, migration, privacy, and source-access design require evaluation |
Sites with stable traffic and a limited set of image widths often benefit from pre-generation. Catalogs with many products, frequent user uploads, or complex crop rules may benefit from on-demand conversion. In either case, the final output should use a stable, reusable cache key and should not be re-encoded on every cache hit.
Coordinating Cache-Control, Content-Type, and Vary
Content-Type: must match the actual bytes, such as
image/aviffor AVIF andimage/webpfor WebP.Cache-Control: fingerprinted immutable assets can use long browser and CDN caching; images overwritten at the same URL require more cautious TTL and invalidation rules.
Vary: when one URL negotiates on
Accept, accurately describe the negotiation dimension and confirm that the CDN cache policy distinguishes the corresponding variants.ETag or Last-Modified: can support revalidation, but each encoded representation needs a correct validator.
Content-Length: should reflect the generated object so transfer size can be monitored accurately.
A CloudFront response headers policy can add, remove, or override headers sent to viewers. Adding Cache-Control to a viewer response does not automatically change CloudFront's own caching behavior. Configure cache TTLs and cache keys through the relevant cache policy and origin response behavior.
CloudFront Image Optimization Checklist
Create a dedicated cache behavior for images instead of sharing an unsuitable policy with HTML or APIs.
Choose between separate format URLs and
Accept-based negotiation.If negotiating, normalize browser support into a small number of format categories.
Include only output-affecting format, width, quality, and crop parameters in the cache key.
Exclude cookies, headers, and query parameters that do not change the image.
Define naming, TTL, invalidation, and versioning rules for source images and generated outputs.
Restrict dynamic parameters so clients cannot generate unlimited variants.
Prevent unintended direct access to S3 or a custom origin.
Log format, dimensions, cache results, conversion time, errors, and output size.
How to Verify the Configuration
Inspect Headers and Actual File Types
curl -I \ -H "Accept: image/avif,image/webp,*/*" \ https://example.com/images/hero curl -I \ -H "Accept: image/webp,*/*" \ https://example.com/images/hero curl -I \ -H "Accept: image/jpeg,*/*" \ https://example.com/images/hero
Check Content-Type, Vary, Cache-Control, CDN cache status, and file size for each request. Do not trust the file extension alone; download samples and verify the actual encoding.
Test What Browsers Actually Select
Use the Network panel to inspect the image URL, type, transfer size, and cache status.
Test AVIF, WebP, and fallback paths in different browsers and on real mobile devices.
Verify that high-DPR screens receive reasonable dimensions and lower-resolution devices do not receive unnecessarily large files.
Ensure the above-the-fold LCP image is not accidentally lazy-loaded and is discoverable early in the HTML.
Compare Lighthouse and PageSpeed Insights diagnostics with real-user image transfer and LCP data.
Monitor CDN and Origin Metrics
After launch, watch cache-hit ratio, origin requests, format distribution, conversion failures, first-generation latency, and bytes transferred. If files become smaller but cache hits fall sharply, total latency and cost may not improve.
Common Mistakes
Using One Quality Number for Every Codec
Quality scales are not directly comparable across encoders. The same numeric value does not represent equal visual quality in AVIF, WebP, and JPEG. Build settings from representative content samples.
Generating a Separate Width for Every Device
Too many sizes increase storage, conversion work, and cache fragmentation. A limited set aligned with major layout breakpoints is usually sufficient.
Setting Vary Without Configuring the CDN Cache Key
Vary describes the negotiation input to shared caches, but each CDN product still needs the correct forwarding and cache-key configuration. Verify behavior with multiple request headers rather than assuming it works.
Using the Full User-Agent to Choose a Format
User-Agent values are complex, unstable, and likely to create many cache variants. Prefer a standards-based capability signal such as the image request's Accept header, then normalize it.
Deleting Every Original Image
Protected high-quality source files make it possible to re-encode images, change crops, or support new formats later. They should not, however, be exposed as uncontrolled oversized downloads to ordinary visitors.
Frequently Asked Questions
Is AVIF Always Better Than WebP?
No. AVIF often has strong compression potential, but encoding time, image-specific quality, and toolchain support also matter. A practical stack may prefer AVIF, use WebP as a broadly supported modern fallback, and retain JPEG or PNG where needed.
Should Image URLs Include File Extensions?
Either model can work. Explicit extension URLs are transparent and pair well with picture and pre-generated files. A stable extensionless URL can support server-driven negotiation, but the response headers and cache key must be correct.
Should the Complete Accept Header Be Added to the CloudFront Cache Key?
Usually not without normalization. Different clients may send many equivalent values. A common strategy is to classify them as AVIF, WebP, or fallback and vary the cache only on that finite result.
Why Is the Site Still Slow After Switching to WebP?
Check pixel dimensions, compression quality, LCP discovery timing, cache-hit ratio, origin latency, the number of images, and lazy-loading behavior. File format is only one part of image performance.
Can Dynamic Image Conversion Become Expensive?
Yes. Cost depends on request volume, the number of generated variants, encoding work, storage, and cache efficiency. Restrict parameters, reuse outputs, pre-generate popular dimensions, and monitor first-generation requests.
Conclusion
Reliable CDN image optimization treats format, dimensions, and caching as one design problem. WebP offers broad modern-browser support, AVIF can reduce the size of many images further, and JPEG, PNG, SVG, or other formats remain useful for fallback and specialized content.
When selecting formats through Accept, return an accurate Content-Type and Vary, and normalize browser capabilities into a finite number of CDN cache variants. Use picture, srcset, and sizes to control actual pixels, restrict transformation parameters, and verify the result with real browsers, CDN logs, and user-performance data. The optimization is successful only when images become smaller, cache efficiency remains high, and visual quality remains acceptable.
References
Google web.dev: Image performance, reviewed August 13, 2026
Google web.dev: Use WebP images, reviewed August 13, 2026
MDN: Accept header, reviewed August 13, 2026
MDN: HTTP content negotiation, reviewed August 13, 2026
AWS: Understand cache policies, reviewed August 13, 2026
AWS: Cache content based on request headers, reviewed August 13, 2026
