Web Delivery: AVIF, WebP, and Keeping Generated Images Fast

A generated hero image at 4K looks incredible in the preview panel and terrible in a Lighthouse report. Nothing about that is a contradiction — image quality and page performance are answering different questions, and a model that can generate more pixels than you need is solving a problem your page never had. The gap between "the biggest image the model could make" and "the image the page should actually serve" is where most of the load-time cost in a generated-content site quietly lives.

Pixel count and file size are not the same problem

It's tempting to treat resolution as the only lever that matters, because it's the one you set at generation time and the one you can see. But the browser doesn't wait on pixel count — it waits on bytes over the wire, and format is doing at least as much work as resolution in determining how many of those there are. Two images with identical dimensions can differ by several times in file size depending purely on which codec encoded them, which is exactly the lever most generated-image pipelines leave untouched after the render finishes.

That's the practical reframe worth starting from: resolution decides how big the image could look. Format decides how expensive it actually is to deliver at whatever size you land on.

What the compression numbers actually say

Three formats matter for a generated-image pipeline right now, and the differences between them are measured, not folklore.

AVIF compresses hardest of the three. Against a matched JPEG source set, AVIF achieves a median size reduction of roughly 50%, compared to roughly 30% for WebP over the same set — meaning AVIF isn't just somewhat smaller than the older alternatives, it's frequently smaller than WebP too, on the same source images.

WebP is the safer, more universally supported middle option. Lossy WebP typically runs 25-35% smaller than an equivalent JPEG, and lossless WebP runs about 26% smaller than an equivalent PNG — a solid, dependable win over the legacy formats even where it doesn't beat AVIF outright.

JPEG and PNG are the baseline everything above is measured against, and at this point they're the format you fall back to for compatibility, not the format you deliberately choose for a new pipeline.

Put simply: if the choice is genuinely open, AVIF wins on raw compression. But "wins on compression" and "is the right default" aren't automatically the same call, and the gap between those two is where the next section matters.

Where AVIF actually loses

AVIF's one real structural gap against the older formats is progressive rendering. AVIF supports lossless compression, animation, alpha transparency, HDR and wide color gamut — but not progressive rendering, the technique that lets a JPEG paint as a blurry approximation early and sharpen in as more data arrives. Without it, an AVIF image is closer to all-or-nothing: nothing visible until the file is fully decoded, rather than a recognizable low-quality version appearing almost immediately.

On a fast connection that distinction barely registers. On a slow one, it can change the perceived experience even when AVIF is winning decisively on total bytes — a smaller file that appears all at once, later, can feel slower to a real user than a larger file that starts painting immediately and refines. That's a genuine, sourced tradeoff, not a reason to avoid AVIF, but it's the detail that should stop "AVIF is smaller, so always use AVIF" from being the whole decision.

Reasons to reach for AVIF beyond raw size

The compression numbers get most of the attention, but AVIF's format-level feature set is its own reason to choose it for specific assets, independent of file size. Lossless mode matters for anything where a compression artifact would actually be visible — flat brand colors, sharp typography inside an image, logo work. Alpha transparency matters for any generated cutout or overlay that needs to composite cleanly onto a page background. HDR and wide color gamut matter for photographic hero imagery on displays that can render the extra range, which is an increasing share of the audience viewing anything on a modern phone or laptop screen. None of those are compression questions at all — they're capability questions, and AVIF is the only one of the three formats answering yes to most of them.

The practical default

For a site serving a mix of generated imagery — hero banners, product shots, thumbnails, in-content illustrations — the durable pattern is content negotiation rather than a single hardcoded format: serve AVIF to browsers that request it, WebP as the fallback, and JPEG or PNG only as the last resort for anything that can't handle either. Modern browser support makes AVIF-first, WebP-fallback a safe default for the large majority of real traffic, and neither format requires you to pick one universally — the <picture> element and equivalent server or CDN-level negotiation exist specifically so the browser gets whichever format it actually supports without you shipping multiple hardcoded versions of every page.

Fixing the pipeline at the source, not just at delivery

Format negotiation solves the codec problem. It doesn't solve the resolution problem, and that one starts upstream of delivery entirely, at generation time. Resolution is worth treating as its own decision rather than defaulting to the model's maximum: pixel count grows with the square of the label, so a 4K generation isn't modestly bigger than 1080p, it's roughly four times the data, for detail that's frequently discarded the moment it hits a phone-width layout or a platform's own re-encoding pass.

The practical version of that inside Versely: generate at the size you'll actually need for your largest real display context — not the model's ceiling by default — and reach for image upscaling as a separate, selective pass only on the specific hero images that need to hold up larger than their native generation size. That's cheaper in practice than generating everything at maximum resolution and compressing down afterward, because you're only paying the larger-file cost on the handful of images that actually need the extra pixels, rather than on every thumbnail and in-content illustration in the batch. Text-to-image generation and the wider model catalog both expose resolution as a setting worth setting deliberately per image, not a default to leave on whatever the picker opens to.

A working checklist

For a generated-image page that needs to load fast without looking compressed:

• Generate at the resolution your largest real display context needs, not the model's maximum ceiling.
• Reach for upscaling selectively, on hero and above-the-fold images specifically, rather than generating everything oversized by default.
• Encode AVIF as the primary delivery format, WebP as the fallback, JPEG or PNG only where neither is supported.
• Remember AVIF's real gap is progressive rendering, not compression — on a page where perceived load speed on slow connections matters more than raw byte count, that's worth weighing against the size win.
• Reach for AVIF specifically, regardless of size, on anything using lossless detail, alpha transparency, or HDR — the cases where it's answering a capability question, not just a compression one.

The takeaway

The model generating your images has no opinion on your Core Web Vitals score, and it shouldn't — that's not its job. Yours is deciding how many of the pixels it can produce actually need to ship, and in which format. Generate deliberately, upscale selectively, and let AVIF-first delivery with a WebP fallback do the rest: the biggest image you can make and the image you should actually serve are very rarely the same file.