How do you optimize images for the web? The 2026 guide to AVIF, WebP and LCP

Why are images the highest-ROI performance fix?

Because they are simultaneously the heaviest and the most visible thing on most pages. According to the 2025 Web Almanac from HTTP Archive, images are responsible for the Largest Contentful Paint on roughly 85% of desktop pages and 76% of mobile pages, and they account for about 48% of total page weight on the median site (Logos Web Designs, 2026). Nearly every page — 99.9% — loads at least one image (DEV / Cloudinary, 2026).

Put those two facts together and the priority is obvious: if your hero image is unoptimized — the wrong format, no responsive variants, no priority hint — you are losing the most important Core Web Vitals battle before the rest of your site even gets a chance to run (Logos Web Designs, 2026). That is also why the return is so high. A single well-built image strategy can cut load times by a large margin, and because the LCP is so often an image, the metric that affects your ranking moves with it. This is the resource side of the Core Web Vitals work, made concrete.

Which format should you use?

AVIF first, WebP as the fallback, JPEG or PNG as the safety net — delivered so the browser picks the best one it supports. AVIF compresses roughly 50% smaller than JPEG and around 30% smaller than WebP at similar quality, with about 94.9% browser support as of early 2026; WebP is about 25–35% smaller than JPEG with roughly 96.4% support (Logos Web Designs, 2026; Two Row Studio, 2026). The <picture> element handles the selection in one block of HTML:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="..." width="1200" height="630">
</picture>

A quick rule covers most cases: photos go to AVIF (with WebP/JPEG fallback), graphics with transparency to WebP (with PNG fallback), and logos and icons to SVG, which stores drawing instructions rather than pixels and scales without loss (imgpact, 2026). One honest trade-off: AVIF can be expensive to encode at scale, so if images are uploaded constantly, a reasonable choice is WebP as the default output with AVIF reserved for high-impact pages (Mohtaweb, 2026).

How aggressively should you compress?

More than most people assume — the trick is finding the point just before quality visibly drops. For photos, WebP at quality 75–85 produces files visually indistinguishable from JPEG quality 85, at roughly a quarter to a third of the size, and AVIF at 60–70 typically matches JPEG 85 (Logos Web Designs, 2026). Push AVIF below 60 and you start to see characteristic block artifacts in flat color regions like skies and walls, so that is the floor for photographs (Logos Web Designs, 2026).

Two adjustments refine it. Illustrations and screenshots — synthetic content with flat areas and sharp edges — tolerate more aggressive compression than photographs, so you can push their quality lower (Logos Web Designs, 2026). And never export at quality 100, which wastes bytes for no visible gain. The reliable way to choose is to test a representative set of your own images visually — faces, gradients, text — with a tool like Squoosh, rather than trusting a single global number (Mohtaweb, 2026).

How do you serve the right size?

By never sending a bigger image than the screen will show. The most common waste is uploading a 4000×3000 photo to display at 800×600 — the browser downloads the full resolution and then scales it down, spending bandwidth for zero visible benefit (imgpact, 2026). Resize every image to its maximum display dimensions before it ships.

Then let the browser choose the right size per device with responsive images. The srcset and sizes attributes offer several widths and let the browser pick based on the screen, so a phone is not forced to download a desktop-sized file:

<img src="photo-800.jpg"
  srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1200.jpg 1200w"
  sizes="(max-width: 600px) 400px, 800px"
  alt="..." width="800" height="600" loading="lazy">

High-density screens like Retina and 4K need a 1.5x or 2x image to look sharp, but you can compress those more aggressively, because compression artifacts are harder to see at high pixel density (Two Row Studio, 2026). One caution: format converters that ignore responsive sizing can still waste huge bandwidth by serving a modern format at the wrong dimensions — fix srcset and sizes first, then formats and quality (Mohtaweb, 2026).

What protects your Core Web Vitals?

Two attributes do most of the work, one for LCP and one for CLS. The single highest-impact thing you can do for LCP is mark your above-the-fold image with fetchpriority="high": Google’s own engineers documented tests where adding that one attribute improved LCP from 2.6 seconds to 1.9 seconds — a 27% gain from a single piece of HTML (Logos Web Designs, 2026). The mirror-image mistake is lazy-loading that same image: lazy-loading the LCP image delays the metric you are trying to improve and is a direct Core Web Vitals failure, so always eager-load anything above the fold (imgpact, 2026).

Lazy-loading still matters — just for everything else. Adding loading="lazy" to below-the-fold images defers them until the user scrolls near, which reduces competition for bandwidth and can let the LCP image download faster (MDN, 2026). The second protective attribute is dimensions: set explicit width and height on every image so the browser can reserve the right space before the file loads. Without them, the browser does not know how tall to make the container, content below jumps when the image arrives, and your CLS score spikes (Logos Web Designs, 2026). The mechanics of both metrics are in our guide on how to pass Core Web Vitals.

What’s the right order to do this in?

Largest image first, one template at a time. Identify the LCP image — usually the hero or featured image — with Lighthouse or Chrome DevTools, create three responsive widths of it in AVIF and WebP, wire up the <picture>, srcset and sizes, make sure it is not lazy-loaded, and set its width and height (Mohtaweb, 2026). Re-test that one page, confirm the LCP moved, then apply the same pattern to the next template.

This sequence matters because it avoids a common trap: optimizing everything at once, then discovering later that a theme update or a plugin conflicts with your changes (Mohtaweb, 2026). One template, one measured win, then scale. Working largest-first also means you spend your effort where the metric actually lives, instead of compressing dozens of small below-the-fold images that were never the bottleneck.

Should you automate it?

Yes — hand-tuning every image does not scale, and the best teams move it into the build. The recommended practice is a build-time image pipeline that automatically generates AVIF, WebP and JPEG variants in several responsive widths, with fetchpriority, explicit width/height and the correct loading attribute wired into the templates, so every deployment ships perfectly optimized assets (Logos Web Designs, 2026). Tools like Vite, a framework image component, or an image CDN such as Cloudinary or ImageKit can do this conversion and sizing for you (LearnHubly, 2026).

This is where a static, build-first architecture has a structural advantage: the image pipeline runs once at build time and bakes the right format, size and attributes into the HTML, so the page is fast by construction rather than patched by a plugin after the fact. It is the same principle behind our guide on whether Astro is good for SEO and performance — do the work at build time, ship the result, and there is nothing left to slow the visitor down.

Don’t forget the alt text

Every image needs descriptive alternative text, and it does double duty. Alt text is what a screen reader announces and what shows if the image fails to load, which makes it an accessibility requirement; it also gives search engines and AI assistants a description of the image, which is an SEO benefit (Two Row Studio, 2026). The standard to aim for is specific and meaningful — “WordPress dashboard showing Core Web Vitals metrics,” not “image123.jpg” or a blank attribute (Two Row Studio, 2026).

The one exception is decorative images that carry no information: give those an empty alt="" so assistive technology skips them instead of reading a filename. Handling alt text properly is also part of the accessibility work in our WCAG 2.2 checklist — another case where one good habit serves performance, accessibility and search at once.

How do you deliver them fast once they’re optimized?

Two delivery habits finish the job. Cache optimized images aggressively, especially when filenames are versioned with a content hash, so a returning visitor never re-downloads an image that has not changed (Mohtaweb, 2026). And serve them from a CDN, so the file travels from a server near the visitor rather than across the world — image-optimizing CDNs can also handle format conversion and resizing at the edge (Hashmeta, 2026). Optimization decides how many bytes you send; caching and a CDN decide how quickly those bytes arrive, and a fast page needs both. On a static, edge-hosted build, both are the default rather than an add-on you bolt on later.

The payoff

The numbers are unusually large for how mechanical the work is. A complete image optimization pass typically reduces total page image weight by 60–80%, and because the LCP is so often an image, that shows up directly in the metric: documented cases include hero-heavy sites dropping from over four seconds to around one second after AVIF conversion and responsive delivery (imgpact, 2026; LearnHubly, 2026).

That is the whole case for treating images as the first place to look when a page is slow. They are half your page weight and the most likely cause of a failing LCP, the fixes are well understood and mostly mechanical, and the result is a faster site that ranks and converts better. For where this fits in the larger picture of speed as a ranking and revenue factor, our pillar on Core Web Vitals and site speed is the place to go next.