Get your audit
Audit finding

Large Unoptimised Images

On most sites, images are the majority of page weight and the reason the largest element takes four seconds to appear.

Check your site

What it means

An image is substantially heavier than the space it occupies needs: a 2,400px JPEG rendered into a 400px column, a hero shipped as an uncompressed PNG, a logo delivered as a 300KB bitmap, or a gallery of full-size photographs loaded before anyone scrolls to them.

Why it matters

The largest element on a page is usually an image, which makes it the Largest Contentful Paint candidate — so image weight is directly what LCP measures. On a throttled mobile connection, an extra megabyte of hero image is several seconds of blank space before anything useful appears. Images without width and height attributes also cause layout shift as they arrive, which is what CLS measures. And on metered connections, the visitor pays for the difference.

How W3Audit detects it

Every image request is recorded with its transfer size, intrinsic dimensions and rendered dimensions, so the report can state the ratio between what was downloaded and what was needed. The check also covers missing width/height attributes, absent loading="lazy" below the fold, formats where a modern alternative would save materially, and — the opposite mistake — lazy loading applied to the LCP image, which delays the metric it should protect.

How severe it is

Critical for images above the fold on primary pages, where the cost lands on LCP for every visitor. High for below-the-fold images on high-traffic pages. Medium where the page is low-traffic or the overshoot is modest. Repeated offenders are reported once with the affected URLs listed, since one hero definition usually explains all of them.

How to fix it

Serve images at the size they are displayed, in a modern format, with dimensions declared and lazy loading everywhere except the LCP image.

<!-- 2400px file in a 600px slot, no dimensions, no lazy loading -->
<img src="hero.png" />

<!-- sized, responsive, dimensioned, eager for LCP -->
<img src="hero-800.webp"
     srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
     sizes="(max-width: 700px) 100vw, 800px"
     width="800" height="450" alt="Audit report score summary"
     fetchpriority="high" decoding="async" />

Below the fold, add loading="lazy" and drop fetchpriority. Aim for hero images under roughly 150KB and content images under 100KB; if a photograph cannot reach that at the size it is displayed, it is being displayed too large.

How to verify the fix

Reload with the network panel open and sort by size: the largest request should be a fraction of what it was, and no image should be more than about twice the pixels it renders into. Then re-measure LCP on a throttled mobile profile several times and take the median. Confirm CLS has not moved, and that the LCP image is still loading eagerly.

Where this sits in your audit

This finding belongs to the Performance category — see the performance audit for everything else reviewed alongside it, or the methodology for how its severity and score contribution are calculated. The website audit checklist includes it as a step you can run yourself.

Get started

Find out whether your site has this problem

A 32-point audit, a severity-ranked report and a live one-hour readout. $2,500 flat.

Request your audit