Image compression for Core Web Vitals

Your largest image often decides your LCP score. Here is how its bytes turn into seconds, how small it needs to be, and what else in the markup matters.

From kilobytes to LCP

LCP is the moment the biggest thing in the viewport finishes rendering. For an image, web.dev splits that time into four parts: server response, resource load delay (how long before the browser even requests the image), download time, and render delay. Compression shrinks only the download part, but on phones it’s often the largest. Play with the numbers:

  • Server response 455 ms
  • Load delay 85 ms
  • Image download 983 ms
  • Render 80 ms

Estimated LCP 1.60 s: good. On this connection the image must be about 1885 KB or less to finish inside 2.5 s.

Google counts LCP as “good” at 2.5 s or less for the 75th percentile of visits (web.dev). Only the download bar shrinks when you compress; the load-delay bar shrinks when the browser can find the image in the HTML early, which is why fetchpriority="high" and not lazy-loading the hero matter as much as bytes.

Checklist

  1. Right dimensions. Serve roughly the displayed width × device pixel ratio, via srcset and sizes. Use the resizer to make each width.
  2. Modern format. AVIF or WebP with a JPEG fallback in <picture>. See WebP vs AVIF.
  3. Sensible quality. 70–80 for photos; check with the compare slider in the compressor.
  4. Discoverable hero. Put the LCP image in the HTML as an <img>, not a CSS background or a JS-injected element, and add fetchpriority="high".
  5. No lazy hero. loading="lazy" on everything below the fold, never on the LCP image.
  6. Reserve space. width and height attributes (or CSS aspect-ratio) stop layout shift as images arrive.

Check your image markup

Paste the <img> or <picture> HTML for your hero or product images (or the “Properly size images” lines from a Lighthouse report). An AI reviewer lists concrete fixes for LCP and CLS. Only the text you paste is sent. No images, no URLs fetched.

0/6000

Sources: web.dev articles “Largest Contentful Paint (LCP)”, “Optimize LCP” and “Optimize Cumulative Layout Shift”. The calculator is a simplified model for intuition; measure real pages with PageSpeed Insights or the Chrome UX Report.

Questions

Which Core Web Vital do images affect most?

Largest Contentful Paint (LCP). On most pages the largest element in view is an image, so how fast that one file arrives and renders sets LCP. Images without dimensions also cause layout shift (CLS).

What LCP counts as good?

Google’s threshold is 2.5 seconds or less at the 75th percentile of page loads, measured separately for mobile and desktop (web.dev/lcp).

Should I lazy-load all images?

No. Lazy-load images below the fold, but never the LCP image; lazy loading delays it until layout is known. Give the hero fetchpriority="high" instead.

Does image compression help INP?

Only indirectly. Interaction to Next Paint is about main-thread work. Very large images can cost decode time, but scripts are usually the bigger INP problem.