Images

The problem

On most pages images are the heaviest thing the browser downloads, and very often the single biggest element on screen, which makes one image the thing your Largest Contentful Paint depends on.

“Optimise your images” hides four separate questions, and each has a different answer:

1. How many bytes? Format, quality and above all the number of pixels.
2. The right bytes for this screen? srcset and sizes.
3. When? Discovery, priority, lazy loading and preloading.
4. How many requests? Sprite sheets, and why the answer changed.

Each has its own experiment below. They share one idea: measure what the browser is really doing before you change anything.

Choosing a format

JPEG

Lossy, universal, still fine for photos. It’s the baseline to beat, not a mistake to fix.

PNG

Lossless. Excellent for flat colour, screenshots and sharp edges, and very large for photographs. Quality settings don’t apply.

WebP

Usually noticeably smaller than JPEG at similar quality, with lossless and transparency options. Supported by every current browser.

AVIF

Often the smallest for photos. The trade-offs are slower encoding and, on weak devices, more decode work. Broadly supported in current browsers.

SVG

Vector. The right choice for logos, icons and simple illustrations: tiny, sharp at any size, styleable. The wrong choice for photographs.

To offer a newer format with a safe fallback, use <picture>. The browser takes the first source it understands:

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

Pixels beat format. Drag the width in the widget. Halving the width removes about three quarters of the pixels, which is usually a bigger saving than any format change, and costs no visible quality if the screen can’t show those pixels anyway.

How the browser chooses

• srcset lists candidate files with their real pixel widths (800w). It describes the files. It doesn’t say how big the image will be on screen.
• sizes tells the browser how wide the image will be laid out, in CSS pixels, before it has done layout. The browser needs this to choose a file early. If you leave it out, it assumes 100vw.
• The browser multiplies that width by the device’s pixel density (2× and 3× screens have more physical pixels per CSS pixel) and picks the smallest candidate that covers it.
• The rules let a browser deviate. It may prefer a file it has already cached, or a smaller one on a slow connection. The widget shows the straightforward rule.

Use srcset and sizes when the same image should be the same picture at different resolutions. Use <picture> with media conditions for art direction, when small screens need a different crop.

Always give images width and height attributes. Browsers use them to reserve the right space before the file arrives. That’s the next experiment.

What the LCP breakdown tells you

The time to paint the hero splits into four parts, and each has a different fix:

• Document TTFB: server and network. Not an image problem.
• Resource load delay: time between the HTML arriving and the browser starting to fetch the image. If it’s large, the image was found late: it lives in CSS, or JavaScript renders it, or you lazy-loaded it. Fix by putting a real <img> in the HTML or preloading.
• Resource load duration: the download. Fix with fewer bytes, or with fewer competing downloads (fetchpriority, lazy-loading things below the fold).
• Element render delay: decode and paint, usually small.

Techniques and their traps

loading="lazy"

Defers an image until it is near the viewport. Excellent for content below the fold. Applied to the hero it delays the most important request. Don’t lazy-load the LCP image.

fetchpriority="high"

Raises the image’s priority in the browser’s request scheduler. Use it sparingly, on the one image that matters. If everything is “high”, nothing is.

rel="preload"

Starts the fetch early. It helps when the browser can’t discover the image by scanning the HTML. When the image is already a plain <img> it adds almost nothing, and a wrong preload can take bandwidth from something more important. For responsive images, use imagesrcset and imagesizes so it preloads the same file the <img> would pick.

width and height

Let the browser compute the aspect ratio and reserve space, so nothing jumps when the image arrives. A score above 0.1 is “needs improvement” and above 0.25 is “poor”.

Common misconceptions

Was it a mistake, or just history?

Sprite sheets solved a real problem: on HTTP/1.1 each request waits for a connection, so fewer requests meant a faster page. That’s the first-visit bar for HTTP/1.1.

This was historically useful, but modern HTTP changes the trade-off. With multiplexing the first-visit gap shrinks, and the costs stay:

• Unused bytes. Every page downloads the whole sheet, including icons it never shows.
• Brittle caching. Change one icon and every visitor re-downloads the lot. The widget’s repeat-visit probability is that effect.
• Maintenance. Offsets in CSS, and awkward scaling and high-DPI handling.
• Accessibility. CSS background icons carry no alternative text.

Where a sheet still makes sense: a very large number of tiny images on a slow, high-latency link, or game and canvas textures (an atlas), where the whole set is needed at once. For UI icons the usual answer today is inline SVG or an SVG sprite referenced with <use>.

The correct approach depends on protocol, how many icons a page really uses, and how often they change. Measure before optimising.

See it on a real page

1. In DevTools open Network, filter to Img, and sort by size. Look for images much larger than the space they fill.
2. In the Performance panel record a page load and open the LCP insight. It reports the same four phases as the widget.
3. Or ask the page directly:

   new PerformanceObserver((list) => {
     for (const e of list.getEntries()) console.log(e.startTime, e.url, e.element);
   }).observe({ type: 'largest-contentful-paint', buffered: true });

4. Lighthouse’s “Properly size images” and “Avoid lazy loading LCP image” audits point at the same problems. This page is the reason behind them.

Model assumptions