Oversized images: compress and convert to WebP/AVIF

What it means

One or more same-host images on this page have a transfer size over 100 KB, read from the Content-Length header of the image response. Images are usually the heaviest resources on a page and the most common cause of LCP delay — a hero image served at 800 KB where 80 KB would do is a direct, measurable contributor to poor LCP.

Why it matters

Largest Contentful Paint measures how long the largest visible element takes to render, and on most pages that element is an image; image transfer size is one of the most direct inputs into it. Google uses LCP as a Core Web Vitals metric and page-experience signal. The 100 KB threshold is a heuristic — most content images fit well under it after correct compression and format choice. Images above it usually mean an original uploaded without resizing, JPEG quality set too high (90+), or a legacy format where WebP/AVIF would be 30–50% smaller. This is a lab-proxy from the response header — the same bytes users and Googlebot download.

How to fix it

1. Resize the image to the maximum size it's displayed at — a 3000px file in a 1200px container wastes two-thirds of the pixels.
2. Convert to WebP or AVIF (cwebp -q 80 input.jpg -o output.webp); WebP is ~25–35% smaller than JPEG, AVIF ~40–50%.
3. Serve modern formats with a fallback via <picture> (<source type="image/avif">, <source type="image/webp">, <img src="...jpg">).
4. For CMS images, use an image CDN (Cloudinary, Imgix, Cloudflare Images) that resizes and reformats on the fly.
5. Set JPEG quality to 75–85 — above 85 adds bytes with little visible gain.

Example

<!-- hero.jpg is 1.8 MB, served at full 4000px width -->
<img src="/img/hero.jpg" alt="Mountain lake at dawn">

<img
  src="/img/hero-1200.avif"
  srcset="/img/hero-800.avif 800w, /img/hero-1200.avif 1200w, /img/hero-2000.avif 2000w"
  sizes="(max-width: 800px) 100vw, 1200px"
  width="1200" height="675"
  alt="Mountain lake at dawn">

Resize images to the largest size actually displayed, convert to AVIF/WebP, and use srcset/sizes so small screens fetch small files. A hero rarely needs to exceed ~200 KB.

When it's not a problem

High-resolution images meant for download, print or zoom (portfolios, product zoom, scientific figures) may legitimately exceed 100 KB — Crawlinx reports the URL and size so you can judge. Images behind a CDN that transcodes lazily can show a large Content-Length on a cold fetch while most users get the optimised version. SVGs are excluded because vector size isn't correlated with visual quality the same way. Only runs when asset inspection is enabled.

How Crawlinx detects it

We probe same-host images and read the transferred size (Content-Length). Any image over 100 KB is flagged with its URL and size, because oversized images are the most common cause of poor LCP.

How common is it?

Not yet observed in our audit sample. We publish this explainer because the check runs on every crawl; once an audited site trips it, this page will break the issue down by platform, gatekeeper, vertical and country.

FAQ

How large should a web image be?

There's no fixed rule, but keep most content images under ~100 KB and a hero under ~200 KB. Serve dimensions matched to the display size, not the original camera resolution.

WebP or AVIF?

AVIF compresses smaller at the same quality and is now widely supported; WebP is a safe fallback. Offer both via <picture> if you need to support very old browsers.

Why does image weight hurt SEO?

The largest image is often the LCP element, so a heavy hero directly slows Largest Contentful Paint — a Core Web Vital Google uses as a ranking signal.