Why image delivery matters for sustainability
Images are often the largest bytes on a page and the most frequent reason a device fetches network data. The way images are produced and delivered affects both the energy used in transit and the compute work on devices and servers. Using an image CDN can reduce waste only when transformations and caching are configured to avoid unnecessary transfers and repeated recomputation. This article focuses on practical patterns for smart resizing at the edge, format negotiation between client and server, and caching strategies that minimize both network transfer and repeated image processing.
Principles to apply before changing architecture
Three principles should guide decisions. First, avoid sending pixels the user will not need. Second, prefer one-time work and long lived caching to repeated on demand transforms. Third, match format and quality to the delivered size and device capabilities. These principles remain true whether the CDN runs in a managed provider, on a private edge, or behind a cache in front of origin.
Smart resizing at the edge: when and how to do it
Smart resizing means producing an image that matches the display size and device characteristics rather than always serving a large master file. Key choices are where to resize, what sizes to expose, and when to prefer server controlled sizes over responsive client selection.
Resize at the edge or during ingest
Resizing at ingest means creating a small, fixed set of precomputed sizes when assets are uploaded. This minimises on demand compute but increases storage and requires anticipating useful sizes. Edge resizing produces tailored sizes on first request and stores the result in the CDN cache. Edge resizing is a good default if traffic patterns are broad and unpredictable because it avoids storing a large number of unused variants in origin storage.
Trade offs to evaluate
Choose precompute when traffic is predictable and the cost of extra storage is lower than repeated compute and bandwidth. Choose edge resize when you expect many unique device and layout combinations, or when you want to support new formats without processing the entire library up front. Instrument actual request patterns to verify assumptions before committing to a single pattern.
Practical patterns
Serve a limited set of canonical widths for common breakpoints and allow the CDN to produce intermediate widths for uncommon requests. For example, provide canonical sizes for thumbnails, small, medium and large layout slots and let the CDN generate ad hoc sizes only when the request does not match a canonical size. Configure cache keys so that generated variants are cached long enough to avoid repeated transforms for the same variant.
Format negotiation: what to negotiate and how
Modern clients and browsers support several image formats that trade off compression, decode cost and feature support. Format negotiation means choosing the best format for the client and delivering that format without causing cache fragmentation or excessive server work.
Use the Accept header and client hints carefully
Servers can read the Accept header to detect support for formats such as AVIF and WebP. Modern browsers also expose client hints that indicate device width and DPR. Use the Accept header to decide format and use client hints to pick an appropriate width and quality. If client hints are used, enable them deliberately so browsers send them only when appropriate.
Avoid cache fragmentation
When the CDN cache key is too granular it will create separate cached objects for each combination of format, width and quality. Keep the cache key explicit and stable. Include the negotiated format and essential client hints in the cache key, but avoid adding headers that vary per request such as cookies or authorization headers. Many CDNs provide configuration to normalise cache keys for image transforms. Use that feature to ensure a generated variant is reused by other identical requests.
Choosing formats
Prefer modern formats for browsers that support them and fall back to broadly supported formats for legacy clients. A common approach is serve AVIF when supported, otherwise serve WebP, otherwise serve JPEG or PNG as appropriate. When a site must support a wide range of older clients, consider server side format negotiation with canonical fallbacks to avoid client side rewrites. Test rendering fidelity on representative devices and verify decoding performance for your most common targets.
Caching strategies that reduce transfer and compute
Caching is the most effective lever to reduce repeated work. There are two layers to consider. The CDN cache prevents repeated origin hits for the same variant. The browser cache prevents repeated network transfers to the user device.
Cache lifetime and invalidation
Set long cache lifetimes for immutable assets. Use strong caching headers such as Cache-Control with a long max-age for content that changes only when the filename or content hash changes. For assets that may be updated in place, use conditional requests and ETag headers so the CDN and browsers can revalidate efficiently. When you need to purge variants after an update, purge by object key and by variant tag so the CDN does not keep serving outdated transforms.
Reduce origin compute by caching transformed variants
Ensure that resized and reformatted variants are stored in the CDN cache rather than recomputed on every request. Many CDNs will cache generated images on first request when the cache key is stable. Configure the CDN to store those generated variants at an appropriate TTL and to serve them from cache without a round trip to origin for subsequent requests.
Edge caching rules that avoid overbroad caching
Avoid caching different visual variants under a single key. If the same URL must produce different outputs for different clients, include the differentiators in the cache key. If you cannot, add Vary response headers to indicate which request headers the cache should consider when storing variants. Use Vary only for necessary headers to avoid unnecessary cache duplication.
Measuring trade offs: what to track and how to compare options
When comparing strategies, focus on three measurable indicators. Track transferred bytes per pageview for image assets, cache hit ratio at the CDN for transformed variants, and origin request rate for image transforms. Use synthetic tests and sampled production telemetry to measure these metrics before and after changes. Synthetic tests can emulate a variety of device widths and formats. Production telemetry reveals actual device and network mixes.
Also measure user perceptual quality. Use visual diff tools to ensure that lower quality or different formats meet business requirements for imagery. Combine automated checks with small user tests for high value pages where visual fidelity matters.
Common implementation pitfalls and how to avoid them
One common mistake is enabling automatic format conversion without aligning cache keys. This creates many small cached objects and increases origin load. Verify CDN behaviour by requesting the same image from different user agents and inspecting cache hits and cache key variants.
Another frequent error is overcompressing images for high density displays. If you target only CSS layout width, you may underdeliver for devices with high device pixel ratio. Use client hints or DPR aware srcset generation to serve higher resolution variants only when needed.
Finally, watch for unnecessary on page images. Image delivery is efficient only when every delivered pixel serves a user need. Lazy load non critical images and avoid background images for decorative elements when an inline CSS or vector can achieve the effect with fewer bytes.
Implementation checklist
- Establish canonical sizes for common layout slots and allow the CDN to generate non canonical sizes on first request.
- Configure cache keys to include negotiated format and necessary client hints while excluding cookies and other volatile headers.
- Enable format negotiation using Accept header with clear fallbacks to ensure broad compatibility without client side logic.
- Set caching headers for immutable variants and use ETag or last modified for versions that may change.
- Instrument three metrics transferred bytes for images, CDN variant cache hit ratio and origin transform request rate.
- Validate visual quality with automated pixel checks and spot user testing on critical pages.
Governance and rollouts
Roll features gradually. Start by enabling edge resizing and format negotiation for a low traffic asset collection or a single page type. Collect the metrics listed above and compare them to a baseline. Use feature flags when enabling new transforms or format targets so rollbacks are simple. Include an audit step for any automatic conversion feature so teams can review a representative sample of transformed images for quality and branding compliance.
Document the CDN cache key policy and a purge procedure so product and content teams can update images without surprising behaviour. Include these topics in a deployment playbook so operations and marketing teams understand how updates propagate.
When to accept extra compute for better bandwidth savings
There are cases where performing a bit more server compute saves large amounts of bandwidth, which can reduce both transfer energy and client CPU for decompression. Examples include converting large PNGs with lots of flat color into compressed vector formats or converting photographic masters into modern compressed formats before serving. Evaluate these cases by comparing the additional transform cost against the expected reduction in transferred bytes and the improvement in cache hit behaviour.
Instrument and review the results periodically. The optimal balance between compute and transfer depends on your traffic pattern, typical device mix and the economics of the CDN or cloud provider you use.