Image optimization for speed: size, format, loading

Why images matter

In the 2025 Web Almanac, the median mobile home page transferred 2.56 megabytes, and images were the largest part of that: 911 kilobytes, more than JavaScript or any other type. On 76% of mobile pages, the Largest Contentful Paint element is an image, which means the image decides whether the page passes LCP. Smaller, better-loaded images are one of the most reliable ways to make a page faster. For the other bytes on a page, see page weight and requests.

Good image work does four things. It sends each visitor an image of the right size, in an efficient format, at a sensible quality, and it loads it at the right time.

1. Size: send what the screen needs

A photo straight from a phone or camera can be 4,000 pixels wide and several megabytes. A page that shows it 400 pixels wide still downloads all of it. Resize every image to the largest size it is actually displayed at, allowing for sharp screens: usually about twice the displayed width.

Responsive images go one step further. You offer several sizes and let the browser pick the one that fits the screen:

<img src="/img/photo-800.jpg"
     srcset="/img/photo-400.jpg 400w, /img/photo-800.jpg 800w, /img/photo-1600.jpg 1600w"
     sizes="(min-width: 900px) 800px, 100vw"
     width="800" height="600" alt="Description of the photo">

The srcset list names the sizes that exist, each with its width in pixels. The sizes value tells the browser how wide the image will be on screen, so it can choose before it downloads anything. Without sizes, the browser assumes the image fills the whole screen width and may download a bigger file than needed.

2. Format: use WebP or AVIF

MDN still recommends a fallback when you use AVIF, because support is newer than for the older formats. Serve a modern format with a safe fallback using the picture element. The browser takes the first source it understands:

<picture>
  <source type="image/avif" srcset="/img/hero-800.avif 800w, /img/hero-1600.avif 1600w" sizes="100vw">
  <source type="image/webp" srcset="/img/hero-800.webp 800w, /img/hero-1600.webp 1600w" sizes="100vw">
  <img src="/img/hero-1600.jpg" width="1600" height="900" alt="Description" fetchpriority="high">
</picture>

3. Quality: compress, then look

Compression removes detail you will not miss. For photos in JPEG or WebP, a quality setting between 75 and 85 is a common starting point. Try a few settings and compare the result by eye at the size it will be shown. A free tool such as Squoosh lets you compare them side by side. For many images at once, use a command-line tool or a library, or a plugin or service that converts images when you upload them.

Remove hidden data you do not need, such as camera information. It adds weight.

4. Dimensions: always set width and height

Add width and height to every <img>, as in the examples above. The browser uses them to work out the shape of the image and reserve the space before the file arrives, so the page does not jump when the image appears. This directly affects CLS, and Lighthouse reports images without these attributes.

5. Loading: lazy-load below the fold, not above

Add loading="lazy" to images that are below the first screen. The browser then downloads them only when the visitor scrolls near them. It works in Chrome 77 and later, Firefox 75 and later, and Safari 15.4 and later.

Never lazy-load the main image at the top of the page. It has to start downloading as early as possible, and Lighthouse flags an LCP image that is lazy-loaded. Add fetchpriority="high" to that one image, or to two at most. The attribute works in Chrome from version 102, Safari from 17.2 and Firefox from 132. Where a browser does not know it, it is simply ignored.

WordPress handles much of this for you. Core has added loading="lazy" to images since version 5.5, leaves the first three images in the content without it, and since version 6.3 adds fetchpriority="high" to the first image that is large enough, at least 50,000 square pixels, as long as the image has its width and height set. Themes, page builders and plugins can override all of this, so check the HTML of your top image yourself.

6. Where an image comes from matters

• Use an <img> tag for the main picture, not a CSS background. Browsers find <img> tags while they read the HTML. Background images are found late, only after the CSS has loaded.
• Avoid loading pictures with JavaScript where you can, for the same reason.
• A CDN or image service can resize and convert images for each visitor automatically, which is the easiest way to serve the right size and format to every device on a large site.

What Lighthouse says about images

In Lighthouse 13, the insight called Improve image delivery lists the files that could be smaller and how much each would save, with one of four reasons:

• Use a modern format. A WebP or AVIF version, or stronger compression, would be smaller.
• Use responsive sizes. The file is larger than it needs to be for the size it is shown at. The report gives both sizes.
• Increase the compression. A higher compression factor would shrink the file.
• Use a video format instead of a GIF. An animated GIF is much larger than the same clip as video.

A separate insight, LCP request discovery, tells you when the main image is found late or lazy-loaded. Fix the largest files first.

A checklist

• Resize images to the size they are shown at.
• Use WebP or AVIF with a JPEG or PNG fallback.
• Compress, and check the quality by eye.
• Set width and height on every image.
• Lazy-load images below the first screen.
• Never lazy-load the main image, and give it fetchpriority="high".
• Use an <img> tag for the main picture.
• Use SVG for logos and icons, and video for animation.

Check your own page

Run the free audit and open the findings about images. Start with the largest file in the list, and check whether the main image at the top is loaded early. Then test again: image fixes show up quickly in the lab numbers.

Sources

• Image file type and format guide on MDN: what each format is for, and the advice to provide fallbacks.
• Responsive images on MDN: srcset, sizes and picture.
• Page weight chapter of the 2025 Web Almanac: the page and image sizes above.
• Optimize Largest Contentful Paint on web.dev: why the main image should be found early and loaded first.