Image Optimization for the Modern Web: WebP, AVIF, and Lazy Loading

A production-friendly implementation looks like this:

The browser evaluates the <source> elements and selects a compatible image. If AVIF is supported, it uses the AVIF version. If not, it tries WebP and eventually falls back to JPEG. The <img> remains essential because it provides the actual image element and fallback. This is much safer than attempting to detect browser support with JavaScript.

Format selection solves one problem, but it does not solve image dimensions. Suppose your desktop hero is 1600 × 900. Sending that same file to a phone displaying the image at approximately 390px wide is wasteful.

Create several versions (hero-480.avif, hero-768.avif, hero-1200.avif, hero-1600.avif) and use srcset:

The w descriptors describe the intrinsic width of each candidate. The browser combines these candidates with sizes and the device's pixel density to select an appropriate resource.

Consider a product card that occupies half the desktop content area (50vw) but the full width on mobile (100vw):

The browser can then choose an appropriate candidate instead of blindly downloading the largest file.

A 400 CSS-pixel-wide image may need an image resource substantially wider than 400 physical pixels on a high-DPI screen. For fixed-width elements like logos, you can provide density-specific resources:

For fluid layouts, however, width descriptors such as 400w, 800w, and 1200w combined with sizes are usually more flexible.

Do not put loading="lazy" on your hero image if that image is the page's Largest Contentful Paint element. Lazy loading can delay its discovery and download. Instead:

Google's web.dev guidance explicitly warns against lazy-loading the LCP image and recommends fetchpriority="high" when an image is likely to be the LCP element. Use it selectively—putting high priority on too many resources weakens its effect.

Aggressive lossy compression on UI screenshots creates fuzzy text, ringing around letters, blocky edges, and blurry icons. Test WebP or AVIF carefully and compare the actual rendered result, or use lossless WebP/PNG where sharp text and transparency are critical.

Instead of aggressively compressing a 4000 × 2500 file that displays at 800 × 500, resize it to approximately the largest size you actually need first. This reduces both file bytes and image decoding/rendering work.

Remember: .hero img { width: 100%; } controls display size, not downloaded file size. Combine CSS with srcset and sizes so the browser downloads the smaller resource.

Determine whether the asset is a photograph, logo, screenshot, UI graphic, icon, decorative background, or hero/LCP image.

Do not upload a 5000px image when the largest rendered size is 1200px.

Create image.avif, image.webp, and image.jpg where they provide a meaningful size/quality advantage.

Export breakpoints such as 400px, 800px, 1200px, and 1600px based on the component's actual rendered sizes.

Include width="1200" height="800" on the <img> tag so the browser reserves layout space and prevents CLS.

Use loading="lazy" below the fold, and fetchpriority="high" (without lazy loading) on the LCP hero image.

Open the actual image at its rendered size and inspect text, faces, edges, gradients, shadows, fine details, and transparency.

Use the Chrome DevTools Network panel, Lighthouse/PageSpeed Insights, and Performance panel to verify which image candidate was actually downloaded and whether the LCP image starts early enough.

• Mistake 1: Lazy-loading everything: Putting loading="lazy" on every image delays the LCP element.
• Mistake 2: Using a 3000px image for a 300px card: CSS resizing doesn't reduce network payload. Use srcset and sizes.
• Mistake 3: Converting everything blindly to AVIF: Measure actual output size and visual quality rather than assuming AVIF is always smaller.
• Mistake 4: Removing width and height: Responsive images still need HTML dimensions to establish intrinsic aspect ratio.
• Mistake 5: Compressing screenshots like photographs: Aggressive lossy settings ruin UI text and sharp lines.
• Mistake 6: Using JavaScript for basic lazy loading: Native loading="lazy" handles normal offscreen images without extra JS overhead.

Before launching a custom website, audit every significant image against this list:

Modern image optimization is not simply "convert JPG to WebP." The real performance improvement comes from combining several decisions:

Use AVIF and WebP where they make sense, keep reliable fallbacks, and let the browser choose between appropriately sized candidates with <picture>, srcset, and sizes.

Most importantly, do not lazy-load your LCP hero image. Critical images need to be discoverable and prioritized early, while images below the fold can be deferred with native loading="lazy".

The objective isn't to make images tiny. It's to deliver the smallest image that looks correct, at exactly the time and resolution the user needs it.