Why Most Websites Still Fail at Image Delivery in 2026

3ev — Thu, 21 May 2026 12:57:38 +0000

Images are one of the biggest performance bottlenecks on the web, and one of the most consistently mishandled. Teams upload whatever they have, usually a large JPG or PNG, and the site deals with the consequences: slow LCP, inflated bandwidth, and Core Web Vitals scores that quietly drag down search rankings.

This post covers what actually moves the needle: modern formats, lazy loading done right, and a just-in-time delivery pipeline we built to handle all of it automatically.

The real cost of unoptimised images

Google's Core Web Vitals have made image performance impossible to ignore. Largest Contentful Paint (LCP), the time it takes for the biggest visible element on a page to render, almost always a hero image, is a direct ranking signal.

An unoptimised hero image doesn't just annoy users. It hurts SEO.

The fix isn't just "compress more". It's about delivering the right format, at the right size, to the right device, ideally without creating a manual process that breaks down as soon as a content editor touches it.

Image CDN vs traditional CDN

A traditional CDN answers: "where is this visitor?"

An image CDN answers: "what does this visitor actually need?"

The difference is transformation. Instead of serving a static file from a nearby edge node, an image CDN generates the optimal variant on request: correct format, dimensions, and compression, then caches it for future visitors.

Pre-generating every variant for every image at every breakpoint is impractical at scale. Dynamic, on-demand generation with caching solves this cleanly: one source file, infinite appropriate outputs.

AVIF and WebP: use them, automate the negotiation

Most sites are still serving JPEG and PNG. Both formats carry significant overhead compared to their modern replacements.

WebP: typically 25–35% smaller than JPEG at equivalent quality. Full browser support. Handles transparency and animation.
AVIF: even better compression than WebP, especially for photography. Browser support is now broad enough to treat it as the primary format in 2026, with WebP as fallback.

Format negotiation happens via the Accept request header - the browser declares what it supports, and your delivery layer responds accordingly:

Accept: image/avif,image/webp,*/*

You shouldn't need to manage this manually. A properly configured image CDN handles it automatically. If you're still manually exporting WebP variants before uploading, your pipeline needs work.

Lazy loading: what to do and what not to do

loading="lazy" is now a browser native, zero-JavaScript way to defer offscreen images:

<img src="photo.jpg" loading="lazy" alt="..." />

But there's one critical mistake we see constantly: lazy loading the LCP image.

Your hero image is almost always your LCP element. Lazy loading it delays the browser from fetching it, which tanks your LCP score.

Never lazy load above the fold. Always lazy load below the fold.

For your hero specifically, go further with a preload hint in <head>:

<link rel="preload" as="image" href="/hero.webp" />

This tells the browser to fetch it before it even starts rendering the page. A meaningful gain for LCP.

How we built a just-in-time image pipeline

We built a custom image CDN that transforms images at request time rather than upload time. The mental model is borrowed from JIT compilation: don't generate the thing until it's actually needed, then cache the result.

The flow:

Editor uploads a standard image to the CMS (any CMS, this is fully agnostic)
A visitor requests a page
The CDN intercepts the image request
If a cached variant exists for that device/format/size combination then serve it immediately (~43 ms average)
If not, transform in real time, cache the result, serve it (~400 ms first hit)

The transformation step handles format conversion (AVIF/WebP with JPEG fallback), responsive resizing based on the requested dimensions, and compression tuned for visual fidelity.

What this looks like operationally:

Storage reduced by ~80% (only source images stored, not variant explosions)
Bandwidth costs cut by up to ~90% once cache warms up
Cache hit rates reaching 90%+ on established sites
43 ms median delivery for cached images

The 400 ms first-hit cost is the trade-off for not pre-generating everything. In practice it's still faster than most unoptimised pipelines, and it disappears as the cache builds.

Worth reading

Core Web Vitals — Google's overview
Largest Contentful Paint (LCP)
Improving image delivery with next-gen formats
How 3ev benefits from just-in-time image delivery techniques