On a typical web page, images account for more than half the bytes. They are also the leading cause of a slow LCP and a janky CLS. Optimising them fixes two of the three Core Web Vitals at once.
Images are usually the single biggest contributor to a page’s weight and the most common reason a page fails Core Web Vitals. They drive Largest Contentful Paint, because the largest element is so often an image, and they drive Cumulative Layout Shift, because an image without dimensions reflows the page when it loads. Getting images right is the highest-leverage performance work on most sites.
Why images dominate LCP
LCP fires when the largest visible element finishes painting. If that element is a hero image, the LCP time is essentially the time it takes to download and decode that image. A 2 MB hero JPEG on a slow connection can push LCP past 4 seconds on its own. Compressing that same image to 200 KB with the Image Compressor can cut LCP in half without any other change to the page.
The compression trade-off
Image compression is a trade-off between file size and visual quality. JPEG handles photographs well and degrades gracefully as you lower quality. PNG is lossless and sharp but heavy for photographs. WebP and AVIF beat both — they produce dramatically smaller files at the same visual quality. For a hero image, exporting as WebP or AVIF at 80–85% quality typically halves the bytes compared to a JPEG with no visible difference.
The right approach is to compress once, from the highest-quality source, to the lowest acceptable quality. Re-compressing an already-compressed image compounds artefacts without much further reduction. Use the Image Convert tool to move to a modern format, then compress the result.
Serving the right size
File size is not just about compression — it is about dimensions. A 4000-pixel-wide photo served to a 400-pixel-wide slot is wasted bytes. Resize the image to the largest size it will actually be displayed at (accounting for retina screens, so roughly double the CSS pixels) with Resize Image before serving it. A correctly sized, correctly compressed image is often an order of magnitude smaller than the original.
Why images cause CLS
When an image loads without width and height attributes, the browser does not know how much space to reserve, so it allocates none. The moment the image arrives, it pushes the content below it down — a layout shift. If the image is above the fold, that shift can push the LCP element itself, compounding the problem. The fix is simple: always include width and height attributes, or use the CSS aspect-ratio property, so the browser reserves the correct box before the image loads.
Lazy loading below the fold
Images below the fold do not need to load immediately. Adding loading="lazy" to those images defers their download until the user scrolls near them, which reduces initial payload and speeds up LCP. But never lazy-load the hero image — it is the LCP element, and deferring it will make LCP worse, not better.
A practical image checklist
- Export hero and content images as WebP or AVIF, not JPEG or PNG.
- Compress to 80–85% quality for photographs; lower for decorative images.
- Resize to the largest display size needed (2x for retina), no larger.
- Always set width and height attributes to prevent layout shift.
- Lazy-load below-the-fold images; never lazy-load the hero.
- Preload the hero image with fetchpriority="high" so it starts early.
The compounding effect
Image optimisation is unusual because a single set of changes improves two Core Web Vitals at once. Smaller, correctly sized images load faster (LCP) and, with dimensions set, do not shift the layout (CLS). On image-heavy pages, fixing images alone can move a site from “poor” to “good” on both metrics without touching JavaScript or server response times.