Core Web Vitals — Google's trio of user-experience metrics — are both a ranking signal and a decent proxy for how fast your site feels. Images influence all three, but they dominate one: on most sites, the Largest Contentful Paint element is an image, and oversized images are the single most common reason an LCP score is poor. The good news is that image fixes are mechanical. Here is the checklist, in order of impact.

1. Serve images at the size they are displayed

The most common waste is dimensional: a 4000-pixel photo squeezed into a 800-pixel column. The browser downloads sixteen times more pixels than it paints. Export or resize blog images to their largest displayed width (a good default is 1200–1600px for full-width content images), and use srcset so phones download phone-sized files. This one step often halves image weight before any compression is applied.

2. Use a modern format

At equal visual quality, WebP is roughly a third smaller than JPG and AVIF smaller still. Converting PNGs to WebP (or to AVIF) is especially profitable because photographic PNGs are often ten times larger than they need to be. Our comparison of JPG vs WebP vs AVIF covers when each format wins and the fallback pattern for older browsers.

3. Compress with intent

Quality 75–85 is the sweet spot for most photographs — visually indistinguishable at normal viewing sizes, dramatically smaller than the 92–100 range most cameras and design tools export by default. Use a tool with a live before/after preview (our website image optimizer runs entirely in your browser) so you can see exactly where quality starts to degrade instead of guessing.

4. Protect the LCP image

The hero image should load as early as possible:

  • Do not lazy-load it — loading="lazy" on the LCP image reliably worsens LCP.
  • Add fetchpriority="high" to the LCP <img>.
  • If the image is a CSS background or rendered late by JavaScript, consider a <link rel="preload" as="image"> hint.
  • Avoid putting the LCP image behind a client-side carousel or animation library.

5. Lazy-load everything below the fold

For every other image, native lazy loading (loading="lazy") is a one-attribute win: offscreen images stop competing with critical resources for bandwidth. Combined with step 1, this typically cuts initial page weight by more than half on image-heavy pages.

6. Reserve space to stop layout shift

Cumulative Layout Shift is the metric images break silently. An image without dimensions renders at zero height, then shoves the page down when it arrives. Always set width and height attributes (or CSS aspect-ratio) so the browser reserves the correct box before the file loads. This costs nothing and eliminates the most common CLS source.

7. Mind interaction responsiveness

Images affect INP indirectly: decoding a huge image on the main thread can delay input handling. decoding="async" helps, but the real fix is the same as everywhere else in this list — do not ship more pixels than the layout uses.

How to measure what images cost you

Before optimizing, get a baseline so you can prove the improvement. PageSpeed Insights gives you the LCP element and per-image savings estimates. The Network tab in your browser's DevTools, filtered to “Img” and sorted by size, shows the worst offenders in seconds — it is common to find one forgotten 5 MB PNG responsible for most of a page's weight. For ongoing monitoring, the Core Web Vitals report in Search Console reflects what real users experience, segmented by mobile and desktop.

A realistic workflow

  1. Run PageSpeed Insights and note the LCP element and the “Properly size images” / “Serve images in next-gen formats” audits.
  2. Fix the LCP image first: correct dimensions, modern format, quality ~80, fetchpriority="high", no lazy loading.
  3. Batch-fix the rest: resize to display size, convert, compress, lazy-load. For a moderate number of images, a browser-based batch pass with our compressor and resizer is free and takes minutes.
  4. Add width/height attributes wherever the audit flags layout shift.
  5. Re-measure. Field data (the CrUX numbers in Search Console) lags weeks behind lab data, so confirm in lab first and be patient with the field graphs.

None of this requires new infrastructure — just discipline about pixels, formats, and one high-priority hero image. For sites with hundreds of frequently changing images, automating these steps is the point where an image CDN starts to make sense.