BlogImage Compression

Image Compression for Core Web Vitals: What Matters Most

Image compression helps Core Web Vitals only when it targets LCP, CLS, and INP correctly. Here is what actually moves the score in 2026.

Updated: July 31, 2026

Image compression improves Core Web Vitals mainly through one path: it shrinks the download phase of your Largest Contentful Paint (LCP) element, which is usually an image. But loading behavior matters more than raw byte size. An eagerly loaded, correctly sized JPEG will routinely beat an aggressively compressed AVIF that is lazy-loaded, discovered late through JavaScript, or slow to decode. What matters most is a short list: serve the LCP image eagerly with fetchpriority="high", set explicit width and height to keep CLS at zero, and deliver AVIF (with WebP and JPEG fallbacks) at the right display size via srcset and sizes. Format choice and compression level are real but secondary wins; how the image loads and how large it is for the viewport usually move the score more than squeezing another 10 percent out of a JPEG.

Key Takeaways

  • Images are the LCP element on most pages, so compression mainly buys you faster LCP, not better INP or CLS by itself.
  • LCP is built from four phases—TTFB, resource load delay, download time, and render delay—and compression only improves download time, while it can worsen render delay if the format is slow to decode.
  • Never lazy-load the LCP image; load it eagerly with fetchpriority="high" so the browser starts it early.
  • Use AVIF first, WebP second, JPEG last via a <picture> element, and pick the right size with srcset and sizes.
  • Always include width and height attributes to reserve layout space and prevent CLS from image loading.

Why Image Compression Alone Does Not Fix Core Web Vitals

Core Web Vitals in 2026 are three metrics: LCP (loading), INP (interactivity), and CLS (visual stability). Google's thresholds are LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, all measured at the 75th percentile of real users. Images barely touch INP directly, but they are deeply tied to LCP and CLS.

The common mistake is treating compression as the whole job. Smaller bytes reduce the resource download time sub-part of LCP, but LCP also depends on:

  • TTFB — how fast the server returns the HTML.
  • Resource load delay — how quickly the browser discovers and requests the image.
  • Resource download time — the only phase compression improves directly.
  • Element render delay — the time from download to paint, which heavy or exotic decoding can lengthen.

An aggressively compressed image that is lazy-loaded, discovered late via JavaScript, or encoded in a slow-to-decode way can land a worse LCP than a slightly larger image loaded eagerly. Compression is one lever; loading strategy and sizing are usually the bigger ones.

What Matters Most: Ranked by Impact on the Score

PriorityActionCWV metric affectedTypical impact
1Load the LCP image eagerly with fetchpriority="high"LCPRemoves seconds of load delay
2Set explicit width and height (or aspect-ratio)CLSEliminates layout shift from images
3Serve AVIF → WebP → JPEG via <picture>LCP50–95% smaller download
4Use srcset/sizes for responsive sizingLCPAvoids sending desktop bytes to phones
5Lazy-load below-the-fold imagesLCP, INPFrees bandwidth and main thread for the hero
6Tune compression quality (AVIF CQ, WebP quality)LCPMarginal, diminishing returns

The top two items are about how the image loads, not how small it is. If your LCP image is lazy-loaded, no amount of compression will rescue the score.

The LCP Image: Where Compression Pays Off Most

Because LCP measures the largest element painted in the viewport, the hero image is where compression and loading strategy compound. Per the MDN/DebugBear analysis of LCP sub-parts, converting a roughly 1 MB hero JPEG to a modern format can cut its weight by roughly 90–95 percent—a saving that directly reduces download time.

Two loading rules for the LCP image:

  1. Do not lazy-load it. Roughly one in six mobile pages incorrectly lazy-load their LCP image. loading="lazy" defers the request until the image is near the viewport, which for an above-the-fold hero means a delayed download and a slow LCP.
  2. Hint it early. Use fetchpriority="high" on the <img> (or rel="preload" with fetchpriority="high" for CSS background images) so the browser prioritizes the request ahead of other images and stylesheets.
<img
  src="hero.jpg"
  srcset="hero-640.avif 640w, hero-960.avif 960w, hero-1280.avif 1280w"
  sizes="(max-width: 600px) 100vw, 50vw"
  width="1280"
  height="720"
  alt="Product hero"
  fetchpriority="high"
  decoding="async"
/>

This standalone example only demonstrates the attributes. For full browser coverage with multiple formats, use the <picture> block shown in the format section, which keeps the same width/height/fetchpriority settings on its fallback <img>.

Choosing a Format: AVIF, WebP, and JPEG

The median mobile page weighs roughly 2 MB, with images accounting for more than half of that weight, per the HTTP Archive. Format choice is the fastest way to cut that weight. In 2026 all major browsers (Chromium, Firefox, and Safari 16.4+) support AVIF, so it is safe as the primary format.

FormatTypical size (2000×2000 photo)Browser support (2026)Best use
JPEG (q80)~540 KBUniversalFinal fallback
WebP (q85)~350 KBAll modernGeneral fallback
AVIF (CQ 28)~210 KBChromium, Firefox, Safari 16.4+Primary delivery format
JPEG XL~260 KBExperimental; not default in any major browserArchival only, not production

File sizes are illustrative and vary with content and encoder settings.

Use the <picture> element so the browser picks the best supported source and older clients fall back gracefully:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" width="1280" height="720" alt="Hero" fetchpriority="high" />
</picture>

A compression caveat: decode time

Heavier compression or exotic formats can increase render delay—the time to decode and paint. AVIF decodes efficiently on modern hardware, but very low quality settings on low-end devices can add measurable decode cost. Test with real device throttling rather than compressing blindly to the smallest file.

Responsive Sizing: Stop Sending Desktop Bytes to Phones

A 1920×1080 hero served to a 400 px-wide phone wastes bandwidth and download time. The srcset and sizes attributes let the browser choose a smaller candidate for narrow viewports. As a rule, generate three to five widths per image (e.g., 640, 960, 1280, 1920) and let the browser negotiate.

This often beats format compression for the LCP score on mobile, because a phone downloading a 640 px AVIF instead of a 1920 px JPEG saves far more than any quality tweak.

CLS: Compression's Silent Failure Mode

Compression does not cause CLS directly, but the workflow around it does. If you omit width and height, the browser cannot reserve space, and when the image finally loads the layout jumps—counted as Cumulative Layout Shift.

Rules to keep CLS at zero from images:

  • Always set width and height attributes (the browser computes aspect-ratio from them).
  • Or set aspect-ratio in CSS if dimensions are dynamic.
  • Reserve space for responsive ads and embeds the same way.
  • Avoid injecting images via JavaScript after layout, which re-triggers shift.

Why Your Score Didn't Improve

If you compressed your images and the score barely moved, the bottleneck is almost never the bytes. Use this table to match the symptom to the real cause.

SymptomLikely causeFix
LCP barely improved after re-compressionLCP image is lazy-loaded or injected by JSRemove loading="lazy", add fetchpriority="high", keep it in initial HTML
Big lab drop, no field changeMeasuring the wrong percentile or cached resultCheck the 75th percentile in field data (Search Console / CrUX), clear cache
LCP improved but CLS got worseNew format changed intrinsic size without dimensionsAdd width and height (or aspect-ratio) on every image
Score stuck on low-end phonesDesktop-sized image still served to mobileAdd srcset/sizes with multiple widths
Slower despite smaller filesVery low quality or slow-to-decode formatRaise quality slightly or verify decode cost on throttled device

The pattern: compression is downstream of loading behavior and sizing. Fix the upstream behavior first, then tune the bytes.

What to Skip (Low-Impact Compression Habits)

  • Spending hours on quality-slider tuning. Once you switch to AVIF/WebP and responsive sizing, quality tweaks yield single-digit percent gains. Stop at a perceptually clean setting and move on.
  • Lossless compression for photos. Lossless is for screenshots and UI art; photos need lossy AVIF/WebP.
  • Serving one giant image and trusting the browser to scale it. This is the most common waste; srcset exists for exactly this.
  • Lazy-loading everything. Lazy-load only below-the-fold images. Lazy-loading the hero is a self-inflicted LCP penalty.
  • Waiting for JPEG XL to "just work." In 2026 it is still not enabled by default in major browsers. Stick with AVIF/WebP/JPEG for production delivery.

Practical Workflow

  1. Identify the LCP element using Chrome DevTools Performance or PageSpeed Insights—confirm it is an image.
  2. Fix loading first. Remove loading="lazy" from the LCP image, add fetchpriority="high", ensure it is in the initial HTML (not injected by JS).
  3. Add dimensions. Set width and height on every image to lock CLS.
  4. Convert formats. Generate AVIF, WebP, and JPEG variants and serve via <picture>. Build-time generation with Sharp or a managed service avoids runtime transcoding.
  5. Add responsive sources. Emit srcset/sizes with three to five widths.
  6. Lazy-load the rest. Add loading="lazy" and decoding="async" to below-the-fold images only.
  7. Re-measure. Use PageSpeed Insights (lab) and the Chrome UX Report / Search Console (field) at the 75th percentile.

If you want a guided path through these steps without hand-rolling a build pipeline, LessMB publishes workflow explainers that walk through image compression and Core Web Vitals fixes in plain terms—useful as a checklist when you are auditing which images on a page actually deserve the hero treatment.

Verification Checklist

  • LCP image identified and confirmed as an image
  • LCP image loads eagerly (no loading="lazy"), with fetchpriority="high"
  • Every image has width and height (or aspect-ratio)
  • AVIF served first, WebP and JPEG as fallbacks
  • srcset/sizes present on images larger than 640 px
  • Below-the-fold images use loading="lazy" and decoding="async"
  • Field LCP at 75th percentile ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1

FAQ

Does image compression improve Core Web Vitals?

Yes, but indirectly. It shortens the download phase of LCP, the metric most affected by images. Without correct loading behavior, dimensions, and format, compression alone yields little improvement.

What is the best image format for Core Web Vitals in 2026?

AVIF, with WebP and JPEG as fallbacks via a <picture> element. AVIF is supported in Chromium, Firefox, and Safari 16.4 and later, and it typically produces the smallest files at acceptable quality.

Should I lazy-load my LCP image?

No. The LCP image should load eagerly with fetchpriority="high". Lazy-loading the largest contentful element delays its download and is a leading cause of slow LCP, affecting roughly one in six mobile pages.

What LCP score should I target?

2.5 seconds or less at the 75th percentile of real users. Above 2.5 seconds is "needs improvement"; above 4 seconds is poor.

Are WebP and AVIF supported in all browsers?

In 2026 WebP works in all modern browsers and AVIF works in Chromium, Firefox, and Safari 16.4 and later. Use a <picture> element with JPEG as the final <img> fallback so older or non-supporting clients still get an image.

I compressed my images but my score did not improve. Why?

Compression only improves the download phase of LCP. If the hero image is lazy-loaded, discovered late by JavaScript, missing width and height, or served far larger than the viewport, loading strategy and sizing are the real bottlenecks. Fix loading behavior and responsive sizing first, then re-measure.

Sources