How to fix oversized and outdated images

What the audit is actually complaining about

“Serve images in next-gen formats” means your images are encoded as JPEG, PNG or GIF where WebP or AVIF would carry the same picture in fewer bytes. “Properly size images” means you are sending more pixels than the layout displays. They are the same underlying problem — shipping weight the visitor never sees a benefit from — and the fix order matters: size first, then format. A 4000-pixel camera photo displayed at 800 pixels wastes more bytes through size than any format can claw back.

Step 1 — find out if images are actually your problem

Fix the thing that costs the most first. Run your page through the checker — if the biggest win is a script or the server, do that guide instead. If it is images, the LCP timeline on your result tells you where the time sits: image fixes only shorten the download phase.

To find which element is the LCP element: DevTools → Performance → run a recording → click the “LCP” marker, or simpler, run Lighthouse in DevTools and open the “Largest Contentful Paint element” audit. It names the exact node. That is the one image whose treatment matters most.

Step 2 — resize to what the layout displays

Export each image at the largest size it is ever displayed, times two for high-density screens. A hero shown at 800×450 needs a 1600×900 source, not the 6000×3375 original. Any image editor does this; so does every build pipeline:

# sharp (Node) — resize and convert in one pass
npx sharp-cli resize 1600 --input hero.jpg --output hero.webp

# or plain ImageMagick
magick hero.jpg -resize 1600x -quality 80 hero.webp

Step 3 — serve WebP, with AVIF where it's worth it

WebP is supported by every current browser and is the sensible default. AVIF is smaller still but slower to encode — worth it for the handful of large images that dominate your weight, unnecessary for icons. The <picture> element serves the best format each browser understands:

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

Keep the width and height attributes — they reserve space and prevent layout shift.

Step 4 — send small screens small files with srcset

A phone at 375 CSS pixels does not need your 1600-pixel hero. srcset lists the sizes you have; sizes tells the browser how wide the image renders so it can pick:

<img
  src="/img/hero-800.webp"
  srcset="/img/hero-400.webp 400w,
          /img/hero-800.webp 800w,
          /img/hero-1600.webp 1600w"
  sizes="(max-width: 640px) 100vw, 800px"
  width="800" height="450" alt="…" />

Step 5 — treat the LCP image as the exception

Everything below the fold should lazy-load. The LCP image is the opposite case: the page is judged by how fast it appears, so tell the browser to fetch it first and never let a plugin lazy-load it:

<img src="/img/hero-800.webp" fetchpriority="high"
     width="800" height="450" alt="…" />

loading="lazy" on the hero is the classic own goal: it moves the one image the visitor is waiting for to the back of the queue. Optimisation plugins that blanket-lazy-load “all images” cause exactly this — every serious one has an “exclude the first N images” setting; set it to 1 or 2.

How to verify

Re-run the check. The image opportunity should shrink or disappear, and if the LCP element is an image, the timeline’s download phase should visibly drop. In DevTools → Network → Img you can confirm the served format and transfer size per image — the “Type” column should say webp or avif, and the hero should be one of the first requests, not the last.

If you'd rather not run a pipeline

Everything above is free and permanent: export at display size, convert with sharp or ImageMagick, write the markup once.