Image Optimization Guide: WebP, AVIF, srcset and Lazy Loading

Images are usually the heaviest thing on a page, and the hero image is often the element that decides your Largest Contentful Paint, one of the three types of Core Web Vitals. The upside is that image optimization is one of the most mechanical speed fixes there is: pick the right format, serve the right size, load it at the right time. This guide gives you the decisions and copy-paste markup for each of those steps.

AI Automation for Dental Practices: A Calmer Front Desk, Explained · 2:57 Subscribe

The four levers

Every image optimization comes down to four questions:

1. Format - is it in the most efficient format the browser supports?
2. Dimensions - is the file roughly the size it is displayed at?
3. Compression - is the quality setting higher than anyone can see?
4. Loading - does it load at the right moment and priority?

Fixing only one of these leaves most of the savings on the table. A perfectly compressed AVIF that is 4000 pixels wide and shown in a 400-pixel card is still wasteful.

Choosing a format

Practical guidance:

• WebP is the safe default for photos and most graphics today. Every current browser supports it.
• AVIF often goes smaller still, especially for photos. It is a good choice for large hero images, with one caveat: AVIF does not render progressively, so the whole file must download before it displays. Compare both on your actual images.
• Do not convert logos and icons to raster formats if you have them as SVG.

Serving AVIF with fallbacks

Use <picture> so each browser takes the first format it supports. Put the most efficient format first and always include the type attribute so browsers skip formats they cannot decode without downloading them.

<picture>
  <source srcset="/img/storefront.avif" type="image/avif">
  <source srcset="/img/storefront.webp" type="image/webp">
  <img src="/img/storefront.jpg" width="1200" height="800" alt="Our storefront on Main Street">
</picture>

The <img> is required. It carries the alt, width and height, and is the fallback for anything else. Since WebP support is universal in current browsers, many sites now just use AVIF with a WebP fallback in the <img>.

Serving the right size with srcset and sizes

A phone with a 400-pixel-wide screen should not download a 2000-pixel image. srcset lists the available sizes; sizes tells the browser how wide the image will display, so it can choose before layout happens.

<img
  src="/img/product-800.webp"
  srcset="/img/product-400.webp 400w,
          /img/product-800.webp 800w,
          /img/product-1200.webp 1200w,
          /img/product-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1200px) 50vw,
         600px"
  width="800" height="800"
  alt="Leather weekender bag in tan">

How to read this:

• 400w, 800w, etc. are the actual pixel widths of each file.
• sizes says: on screens up to 600px wide, the image fills the viewport; up to 1200px, it fills half; otherwise it is 600 CSS pixels wide.
• The browser multiplies the slot width by the screen's pixel density and picks the smallest file that covers it. A 2x phone with a 390px slot looks for roughly 780 pixels and picks the 800w file.

Common mistakes:

• Omitting sizes. Without it, the browser assumes 100vw and may download a far larger file than needed for an image in a sidebar or grid.
• sizes that do not match your CSS. If the image is actually 300px wide in your layout, say so.
• Only one or two candidates. Offer enough steps (for example 400, 800, 1200, 1600) to cover phones through high-density desktops.

For a fixed-size image, such as a logo or avatar, pixel-density descriptors are simpler:

<img src="/img/avatar-96.webp"
     srcset="/img/avatar-96.webp 1x, /img/avatar-192.webp 2x"
     width="96" height="96" alt="Jane Doe">

Art direction

When the mobile version needs a different crop, not just a smaller file, use <picture> with media:

<picture>
  <source media="(max-width: 600px)" srcset="/img/hero-portrait.webp">
  <img src="/img/hero-wide.webp" width="1600" height="700" alt="Team in the workshop">
</picture>

Compression

Every format has a quality dial, and the default in many tools is higher than necessary. The right setting depends on the image: detailed photos tolerate more compression than flat graphics with sharp edges or text.

A practical process:

1. Export at the largest size you need (for your biggest srcset candidate).
2. Compress a few representative images at decreasing quality levels and compare them side by side at real display size.
3. Pick the lowest setting where you cannot see a difference, and apply it to similar images.

Tools:

• Squoosh (in the browser) for comparing formats and quality visually.
• cwebp and avifenc on the command line:

cwebp -q 80 input.jpg -o output.webp   # quality values are starting points, not rules
avifenc -q 60 input.jpg output.avif

• sharp (Node.js) or ImageMagick for batch resizing and conversion in a build step.
• Image CDNs that resize and convert on the fly based on the requesting browser.
• WordPress: core supports WebP and AVIF uploads (AVIF since 6.5, if your server's image library supports it), and optimization plugins can convert existing libraries in bulk.

Also strip metadata (EXIF camera data, embedded thumbnails) unless you need it. Most tools do this by default.

Loading: lazy, eager and priority

Lazy load below-the-fold images

Native lazy loading is one attribute, supported in all modern browsers (Chrome 77+, Firefox 75+, Safari 15.4+):

<img src="/img/gallery-7.webp" loading="lazy" width="800" height="600" alt="...">

Iframes support it too, which is useful for YouTube and map embeds:

<iframe src="https://www.youtube.com/embed/VIDEO_ID" loading="lazy"
        width="560" height="315" title="Product demo"></iframe>

The browser starts loading lazy images before they scroll into view, based on a built-in distance threshold that varies with connection speed, so users rarely see them pop in.

Never lazy load the hero

Images visible on first load, and especially the LCP image, should load eagerly. Lazy loading them delays the request until layout, which directly hurts LCP. Give the hero a priority boost instead:

<img src="/img/hero.avif" fetchpriority="high" width="1600" height="700" alt="...">

More on this in improving Largest Contentful Paint.

Always set width and height

Width and height attributes let the browser reserve space before the image arrives, preventing layout shift. Without them, lazy-loaded images in a gallery may all report as 0x0, look like they fit in the viewport, and load at once. See fixing CLS.

Image optimization checklist

• Photos in AVIF or WebP with a fallback
• Logos and icons as SVG
• Animated GIFs replaced with <video autoplay muted loop playsinline>
• srcset with several widths and an accurate sizes
• Quality checked visually, metadata stripped
• loading="lazy" on below-the-fold images and iframes only
• fetchpriority="high" and no lazy loading on the LCP image
• width and height on every <img>
• Long cache lifetime on image files (for example Cache-Control: max-age=31536000, immutable for versioned filenames)

Frequently asked questions

Should I use AVIF or WebP?

Test both on your own images. AVIF often produces smaller files, particularly for photos, but encodes more slowly and does not render progressively. WebP is a reliable default with universal support in current browsers. Using <picture> lets you serve AVIF with WebP as the fallback.

Does lazy loading hurt SEO?

Native loading="lazy" is understood by Google and does not hide images from indexing. Problems arise with JavaScript lazy-loading libraries that leave the real URL in a data-src attribute, and with lazy-loading the hero image, which hurts LCP.

Do CSS background images support srcset or lazy loading?

The loading attribute only works on <img> and <iframe>. For backgrounds you can use image-set() in CSS for formats and resolutions, but background images are discovered late by the browser. For important images, especially the LCP image, a real <img> element is usually the better choice.

Can I convert all my existing images automatically?

Yes. Build tools, image CDNs and WordPress optimization plugins can convert and resize in bulk. Keep the originals, check a sample visually after conversion, and make sure your markup actually serves the new files.

What to do next

Start with your three most-visited pages: find the largest images in DevTools > Network (filter by Img, sort by size), convert them to AVIF or WebP, add srcset, and make sure the hero is not lazy-loaded. Then run a free audit to confirm your LCP and performance score improved. If you run WordPress, our guide to speeding up WordPress covers the platform-specific settings.

Sources

• Choose the right image format - web.dev
• Browser-level image lazy loading - web.dev
• Responsive images - MDN
• Image file type and format guide - MDN
• An image format for the Web (WebP) - Google for Developers