Image Optimisation Example: 4.2MB Wasted, 73% Legacy Formats

Of the six numbers on this report, one is a genuine emergency and it is not the 4.2MB. It is the single row saying the LCP image carries loading="lazy".

Lazy-loading works by deliberately withholding the image until the browser has calculated layout and determined the image is near the viewport. For an image below the fold, that is exactly what you want. For the largest element in the viewport — the one LCP is measured against — it is self-sabotage. You have instructed the browser to delay the very thing your score depends on.

The rule is simple and absolute: never lazy-load anything above the fold, and above all not the LCP element. The report shows 3 of the 27 above-the-fold images are lazy — all three are working against you, and one of them is the one that counts.

The recommended fix applies preload and fetchpriority="high". They are different tools and it is worth knowing which is doing the work.

For a plain <img> in the HTML, fetchpriority="high" alone is usually sufficient — the scanner already found it, and you are simply promoting it. The preload adds little and, done carelessly, actively harms: a preload for a URL that differs even slightly from the one the browser eventually requests downloads the image twice. A mismatched imagesrcset, a different query string, a CDN transform — any of these produce two downloads, and you have made the page slower while trying to make it faster.

Where preload genuinely earns its place is a CSS background-image hero. The scanner reads HTML, not CSS, so it cannot see that URL until the stylesheet has downloaded and parsed — a guaranteed late discovery of your most important image. If your LCP element is a CSS background, that is the bug, and the honest fix is to make it a real <img>.

Format conversion is the headline finding, but it is not where the real waste is. The real waste is resolution.

Converting a 1600px-wide hero from JPEG to WebP might save 90% of its bytes. Serving a 400px-wide version of it to a 400px phone saves considerably more than that — and most of the traffic is phones. Without srcset, every visitor downloads the desktop image, scales it down in the browser, and pays full price for pixels that are then discarded.

And note the width and height attributes. They are not legacy cruft. The browser uses them to compute the aspect ratio and reserve the correct space before the image arrives — which is what prevents the content below from jerking downward when it loads. Omitting them is one of the largest single causes of CLS. Set them to the image's intrinsic dimensions and let CSS handle the display size.

73% on legacy formats sounds alarming. The right response is less sweeping than "convert everything".

The /icons/feature-cloud.png row is the one to notice. 340KB for an icon, saving 99% as SVG. That is not an optimisation problem, it is a format problem — a vector graphic was exported as a raster image, and no amount of compression fixes that. Every icon and logo on the site should be SVG, and there are almost certainly more than the ten this report found.

Use <picture> with <source type="image/avif">, then WebP, then a plain <img> fallback — the browser takes the first format it understands and there is no JavaScript involved. Better still, put an image CDN in front of it all: format negotiation, resizing and srcset generation become one URL parameter, and you never hand-export another variant.

The report files this under accessibility, which is right and is the more important reason. There is a second one that gets forgotten.

Google Images is a search engine, and alt text is the primary way it understands what an image contains. For anything visual — products, recipes, tools, interfaces, places — image search is a real and frequently unmeasured traffic source, and 218 images with no alt text are 218 images invisible to it.

Write the alt for the person listening to it. Describe what the image conveys in its context, not what it depicts — the same screenshot needs different alt text on a pricing page and in a tutorial. Keyword-stuffed alt text is read aloud, to a human being, and it is both an accessibility failure and, at scale, a spam signal. And one final trap worth checking: never block your image directories in robots.txt. Googlebot renders pages, and an image it cannot fetch is an image it cannot index — nor can it judge whether the page is mobile-friendly.

Why should I never lazy-load my LCP image?

Because lazy-loading works by deliberately withholding the image until the browser has parsed the CSS, built the layout and determined the image is near the viewport. For an image below the fold that is exactly right. For the largest element in the viewport — the one LCP is measured against — you have inserted the entire CSS and layout pipeline in front of your most important resource, and stopped the preload scanner from fetching it early. Removing the attribute can improve LCP by a second or more and costs nothing.

Do I need both preload and fetchpriority on my hero image?

Usually not. They do different jobs: fetchpriority changes the priority of a resource the browser has already found, while preload changes when it is discovered. For a plain img in the HTML the preload scanner has already found it, so fetchpriority="high" alone is generally sufficient. A careless preload actively harms — if the preloaded URL differs even slightly from the one eventually requested, through a mismatched imagesrcset, a query string or a CDN transform, the image downloads twice. Preload earns its place for resources the scanner cannot see, such as a CSS background-image hero.

Is converting to WebP the biggest saving available?

No — resolution usually beats format. Converting a 1600px hero to WebP might save 90% of its bytes, but serving a 400px version of it to a 400px phone saves more, and most traffic is phones. Without srcset every visitor downloads the desktop image and scales it down in the browser, paying full price for pixels that are then discarded. The 94 images with no srcset are a larger opportunity than the format distribution table.

Why does srcset need a sizes attribute?

Because srcset only lists what is available — sizes tells the browser how wide the image will actually be displayed. It must be in the HTML, since the browser chooses which file to download before it has parsed your CSS. Omit sizes and the browser assumes the image spans the full viewport width, picks the largest file available, and the entire srcset does nothing.

Do width and height attributes still matter?

Very much. The browser uses them to compute the aspect ratio and reserve the correct space before the image has arrived, which is what stops the content below from jerking downwards when it loads. Omitting them is one of the largest single causes of CLS. Set them to the image's intrinsic dimensions and let CSS control the display size.

Should I convert every image to a modern format?

Almost — with one firm exception. Keep your og:image as JPEG or PNG, because support for WebP and AVIF among social scrapers is uneven and the failure mode is a completely blank share card. Also note that icons and logos should not be raster images at all: a 340KB PNG icon is a format problem, not a compression problem, and it should be SVG.

Does missing alt text really cost me traffic?

It costs two things. Accessibility is the more important one — alt text is what a screen reader announces. But Google Images is also a search engine, and alt text is the primary way it understands what an image contains, so for anything visual it is a real and frequently unmeasured traffic source. One caveat: alt="" is a correct answer for decorative images, and it is not the same as omitting the attribute. That means "218 missing alt" is not 218 descriptions to write, and a bulk script that generates alt text for every image on the site makes accessibility worse rather than better.