Image Optimization at the Edge: A Practical Guide
How to cut page weight with modern formats, correct sizing, edge caching and lazy loading — measured against LCP rather than a compression ratio.
Quick answer
Serve AVIF with a WebP fallback, generate responsive widths and let the browser pick with srcset and sizes, cache transformed variants at the edge keyed by format and width, mark the LCP image as eager with fetchpriority high, and lazy-load everything below the fold. Most sites lose more to oversized dimensions than to a suboptimal codec.
The real problem is dimensions, not codecs
In store audits I run, the most common single fix is not switching to AVIF. It is that a 2400px product photo is being displayed in a 400px card. You can win 60% of the page weight before touching a compression setting.
The pipeline
- Accept the original once and store it in object storage untouched.
- Derive variants on demand: width × format, cached at the edge.
- Serve via a URL that encodes the transform, so the cache key is deterministic.
- Purge by prefix when the source asset changes.
<img
src="/cdn/product.jpg?w=800&f=auto"
srcset="/cdn/product.jpg?w=400&f=auto 400w,
/cdn/product.jpg?w=800&f=auto 800w,
/cdn/product.jpg?w=1600&f=auto 1600w"
sizes="(max-width: 768px) 100vw, 800px"
width="800" height="1000"
alt="Charcoal linen shirt photographed flat on a pale background"
loading="lazy" decoding="async" />Format decisions in one table
| Format | Use for | Notes |
|---|---|---|
| AVIF | Photography | Best ratio, slower to encode — cache it |
| WebP | Fallback everywhere | Universally supported today |
| SVG | Logos, icons, diagrams | Sanitise any user-uploaded SVG |
| JPEG | Last-resort fallback | Keep quality around 78 |
Always reserve the space
Width and height attributes, or an aspect-ratio, prevent layout shift. CLS is the cheapest Core Web Vital to fix and the one most often left broken.
Measuring the result
- LCP element and its load time, from field data not a lab run.
- Total image bytes on the landing and product templates.
- Cache hit ratio on the transform endpoint — under 90% means your cache key is wrong.
- CLS after the fix, to confirm you did not trade one metric for another.
Checklist
- Originals stored once, variants derived on demand
- Deterministic cache key of width + format + quality
- AVIF with WebP fallback via content negotiation
- srcset and sizes on every content image
- width/height or aspect-ratio always set
- LCP image eager with fetchpriority=high
- Everything below the fold lazy-loaded
- Edge cache hit ratio monitored above 90%
- Descriptive alt text on every meaningful image
Common mistakes
- Lazy-loading the hero image.
- Shipping a 2400px source into a 400px slot.
- Cache keys that include a session or timestamp, destroying hit ratio.
- Empty alt text on informative images, hurting accessibility and image search.
- Re-encoding on every request instead of caching the variant.
Frequently asked questions
Is AVIF always better than WebP?
For photographs, usually 20–30% smaller at similar quality. For flat graphics the gap narrows and encode cost rises, so cache aggressively and keep WebP as the fallback.
Does image optimisation affect SEO?
Indirectly and strongly. LCP is a ranking signal, and descriptive alt text plus stable URLs drive image search traffic.
Should I optimise images at build time or on demand?
On demand with edge caching for user-generated or catalogue content; build time for a fixed set of marketing assets.
Summary
Right-size first, serve modern formats through a deterministic cache key, reserve layout space, keep the LCP image eager, and validate with field LCP and cache hit ratio rather than a compression percentage.
working on something like this?