Image Optimisation Beyond WebP: AVIF, LQIP and the New Defaults

The baseline has moved

Two years ago, serving WebP with a JPEG fallback was a reasonable production default. In 2026, it is the minimum. AVIF is supported everywhere that matters, placeholders are expected, and the tools that used to feel new are now table stakes. This is the setup we ship on image-heavy sites, and why.

AVIF is ready

AVIF (AV1 Image File Format) has cleared the browser-support bar that was holding it back. Chrome, Edge, Firefox, Safari and the majority of mobile browsers render it natively. The remaining long tail is small enough that WebP is a fine fallback, and old-browser JPEG should be the third tier.

Compared with WebP, AVIF produces noticeably smaller files at comparable perceptual quality, especially on photographic content at larger dimensions. The wins are bigger on hero images and product photography than on small icons or flat graphics, where WebP was already efficient.

Our default encoding chain now looks like this:

1. AVIF as the primary format.
2. WebP as the fallback for browsers that do not support AVIF.
3. JPEG or PNG as the last resort.

Served via <picture> with properly ordered <source> elements, the browser picks the best format it understands and the rest do not download.

Placeholders and perceived performance

An optimised image still feels slow if the user stares at a blank box while it loads. Placeholders fix that.

LQIP

Low-Quality Image Placeholders are tiny, heavily compressed versions of the final image, inlined as a data URI or served as a blurred preview. The browser renders them instantly, then swaps in the full image when it arrives. Done well, the transition is imperceptible and Largest Contentful Paint improves because the layout is stable from the first frame.

Blurhash

Blurhash encodes an image as a 20-30 character string that decodes to a blurred representation. It is smaller than LQIP on the wire and avoids the extra image request, at the cost of a small runtime decode. For CMS-driven sites where the placeholder is stored alongside the image metadata, blurhash is efficient.

ThumbHash and friends

ThumbHash is a newer competitor that produces a more faithful placeholder from a similarly small string. For our projects, either blurhash or ThumbHash gives a better experience than the solid-colour placeholder we used to ship.

Responsive images done properly

srcset and sizes are not optional. A responsive image served at a single size will always be wrong for most viewports.

<picture>
  <source
    type="image/avif"
    srcset="hero-640.avif 640w, hero-1024.avif 1024w, hero-1600.avif 1600w, hero-2400.avif 2400w"
    sizes="(min-width: 1024px) 1024px, 100vw" />
  <source
    type="image/webp"
    srcset="hero-640.webp 640w, hero-1024.webp 1024w, hero-1600.webp 1600w, hero-2400.webp 2400w"
    sizes="(min-width: 1024px) 1024px, 100vw" />
  <img
    src="hero-1024.jpg"
    alt="..."
    width="1600"
    height="900"
    loading="lazy"
    decoding="async" />
</picture>

Width and height attributes are critical. They let the browser reserve space and avoid layout shift, which directly protects your CLS score.

Art direction

For responsive layouts where the mobile crop differs from the desktop crop, <picture> can serve different images by media query. We use this on hero banners where a landscape photo does not work at 375px wide.

Automated pipelines

Nobody should be generating these variants by hand. The tooling is mature.

Sharp

At the build-time end, Sharp is the workhorse. Fast, well-maintained, and underneath most of the framework integrations below.

next/image and gatsby-plugin-image

Framework-level image components give you AVIF, WebP, responsive variants, blur placeholders and lazy loading out of the box. If you are on Next.js or Gatsby, you should be using them. The remaining work is authoring the source images at enough resolution and picking sensible sizes.

Cloudinary and imgix

For CMS-heavy sites where editors upload originals, a URL-based image CDN is hard to beat. You store the original, then request derivatives with URL parameters. Caching handles the rest. The pricing is not free, but the developer time saved is a larger number in AUD than the bill.

Cloudflare Images and Vercel Image Optimisation

Platform-native options that sit closer to your deployment. Cloudflare Images is well-priced for high-traffic sites.

Budgets and Core Web Vitals targets

We ship image-heavy pages against a few rules of thumb.

• The LCP image should be well under a megabyte on a fast connection, and preloaded in the <head> with fetchpriority="high".
• Above-the-fold images should not be loading="lazy". That attribute belongs on below-the-fold content.
• Total image weight on a marketing page should fit comfortably inside the performance budget for mobile 4G.
• CLS should be zero. Always set dimensions or aspect ratios.
• LCP should be well inside the Google "good" threshold. If it is not, the problem is almost always the hero image.

What we stopped doing

A few habits we have quietly retired:

• Serving only WebP. AVIF savings are real enough to justify the extra encode step.
• Using solid-colour placeholders. Blurhash or ThumbHash is a better experience for a tiny amount of extra work.
• Lazy-loading the hero. Lazy-loading below-the-fold is correct. Lazy-loading the LCP image actively hurts performance.
• Hand-rolling <picture> markup for CMS content. A helper component that takes a single source asset and emits the full responsive ladder is worth its weight in reduced bugs.

Measuring the wins

Optimisation without measurement is guesswork. We check image performance with a handful of tools in the normal rotation: Chrome DevTools Lighthouse for CWV on representative pages, WebPageTest for real-device waterfall analysis, and PageSpeed Insights with field data from CrUX to see how real users experience the site. Bundle and asset weight should be tracked in CI on every deploy so a careless PR does not quietly add a 2MB hero.

A pattern worth stealing: snapshot the total image weight of your top ten pages on every release and alert on regressions. Image bloat creeps in one commit at a time, not all at once. By the time someone notices LCP has slipped you have six months of creep to untangle.

Where we start on a new build

Every new image-heavy project we pick up in 2026 starts with: AVIF plus WebP plus JPEG fallback, blurhash placeholders stored alongside CMS content, responsive srcset driven by a helper component, and LCP images preloaded. If any of that is missing from your current site, there is a quick performance win hiding there. Happy to take a look at your image pipeline and point out where the savings are.