Where Images Make or Break Your Vitals Score

Images decide two of the three Core Web Vitals on most pages: they are usually the Largest Contentful Paint element, and they are the most common source of layout shift. This guide maps each metric to the image decision behind it, then shows where AVIF's smaller bytes move the needle.

What Core Web Vitals measure in 2026

Core Web Vitals are three field-measured metrics that score loading, responsiveness, and visual stability. Google evaluates each at the 75th percentile of real Chrome users over a rolling 28-day window.

Metric	What it measures	"Good" threshold
Largest Contentful Paint (LCP)	Loading speed of the largest element	< 2.5 s
Interaction to Next Paint (INP)	Responsiveness to user input	< 200 ms
Cumulative Layout Shift (CLS)	Unexpected visual movement	< 0.1

INP replaced First Input Delay as a Core Web Vital on 12 March 2024. A page passes the assessment only when all three p75 values land in "Good". Lighthouse approximates these scores in the lab; the ranking-relevant numbers come from the Chrome User Experience Report.

Why the LCP element is usually an image

The LCP element is the largest image or text block visible in the viewport on first paint. On content and commerce pages, that element is almost always an image: the hero, the lead product photo, or the article header.

That makes most LCP work a single question: how fast can one image reach the screen? Three pages typically compete for the LCP slot.

Marketing pages — the full-bleed hero banner.
Product pages — the primary product photograph.
Article pages — the featured header image.

When the LCP element is text instead, image weight still matters indirectly, because heavy image downloads compete for bandwidth and delay everything else.

The four sub-parts of an image LCP

An image LCP breaks into four sequential sub-parts, per web.dev's LCP optimisation guide. Each one is a separate place to lose time.

Time to First Byte (TTFB) — server response before any HTML arrives.
Resource load delay — the gap between TTFB and the browser starting the image download.
Resource load duration — the time to actually download the image bytes.
Element render delay — decode plus paint after the bytes finish arriving.

On the median site with poor LCP, load delay alone is roughly 1.3 seconds — about four times the download itself. AVIF attacks sub-part 3 directly and helps sub-part 2 by leaving more bandwidth free.

Where AVIF cuts the most

AVIF shrinks load duration by storing a photo in roughly half the bytes of an equivalent JPEG, and 20–25% fewer than WebP. A 1200×675 hero that is 110 KB as JPEG is often 35–55 KB as AVIF.

Smaller transfer means fewer round trips on slow links, where LCP problems concentrate. Convert your hero with Convert JPG to AVIF or Convert PNG to AVIF, and see AVIF for the full compression numbers.

Fixing resource load delay: discovery and priority

Load delay shrinks when the browser discovers the LCP image early and downloads it at high priority. Two attributes solve two distinct problems.

preload fixes late discovery; fetchpriority="high" fixes low priority. A viewport <img> starts at medium priority, so fetchpriority="high" removes the priority-upgrade lag the moment the image is found.

<head>
  <link
    rel="preload"
    as="image"
    href="/img/hero-1200.avif"
    imagesrcset="/img/hero-800.avif 800w, /img/hero-1200.avif 1200w, /img/hero-1800.avif 1800w"
    imagesizes="100vw"
    type="image/avif"
    fetchpriority="high"
  />
</head>
<body>
  <picture>
    <source
      type="image/avif"
      srcset="
        /img/hero-800.avif   800w,
        /img/hero-1200.avif 1200w,
        /img/hero-1800.avif 1800w
      "
      sizes="100vw"
    />
    <img
      src="/img/hero-1200.jpg"
      width="1600"
      height="900"
      alt="Product hero"
      fetchpriority="high"
      decoding="async"
    />
  </picture>
</body>

Never add loading="lazy" to the LCP image. Lazy-loading the hero is the single most common LCP regression — covered in AVIF Lazy Loading. Keep the image in server-rendered HTML so the preload scanner finds it without waiting for JavaScript.

Element render delay: AVIF decode cost

Render delay is the decode and paint work after the bytes arrive, and AVIF decodes slower than JPEG or WebP. On low-end mobile CPUs that extra decode can eat into the transfer savings.

The trade is real but usually favourable: a 60 KB transfer saving on a 4G link buys far more time than AVIF's few extra milliseconds of decode cost. The exception is very weak hardware.

decoding="async" keeps decode off the main thread so it never blocks first paint.
Smaller dimensions reduce decode cost directly — serve a 1200px image, not a 4000px one.
Measure decode on real target devices, not Lighthouse, which runs on fast hardware.

Tune the encoder for the size/decode balance in AVIF Compression Settings. For the format trade-offs, compare AVIF vs WebP and AVIF vs JPG.

CLS: reserve space before the image loads

Layout shift happens when an image loads after surrounding content and pushes it down. The fix is to reserve the image's box before its bytes arrive.

Switching JPEG to AVIF changes nothing about CLS on its own — but a smaller file that loads sooner reduces the window in which an unreserved image can shift the page.

Set width and height on every image

<img src="/img/photo.avif" width="1200" height="675" alt="…" />

The browser reads width:height as an aspect ratio and reserves the correct box. With responsive CSS the attributes stop being fixed pixels and become the ratio hint.

img {
  max-width: 100%;
  height: auto;
}

Use aspect-ratio for dynamic images

.product-image {
  aspect-ratio: 4 / 3;
  width: 100%;
  background-color: #f5f5f5;
}

Use aspect-ratio when intrinsic dimensions are unknown at render time, or for placeholder boxes filled later by client code. A neutral background colour hides the empty box until the image paints.

Non-image CLS sources

CLS is not only an image problem. Audit these contributors with Lighthouse, which lists shifts by element.

Late-injected ads, for example a top banner that loads after the fold.
Web fonts swapping after a fallback, for example a wide font replacing a narrow one.
Cookie banners and consent dialogs pushing content down.

INP: keep image work off the interaction path

Images rarely dominate INP, because INP is driven by JavaScript main-thread time. They hurt it only when image work competes for the same thread during an interaction.

Three image patterns cause INP regressions.

Synchronous decode in a click handler — swapping an image and decoding it inline charges the decode to the interaction. Use decoding="async" or img.decode() off the handler.
Bulk paint on filter or sort — revealing a large grid forces many decodes at once. Lazy-load off-screen items per AVIF Lazy Loading.
Main-thread image manipulation — canvas crop or filter work blocks the next paint. Move it to a Web Worker or OffscreenCanvas.

AVIF's smaller files do not change INP directly, but fewer bytes mean less paint work when many images enter the viewport together.

A measurement workflow

Measure with field data first, then reproduce regressions in the lab. The two answer different questions: field tells you what users experience, lab tells you why.

Read the field — open PageSpeed Insights for the page. The top panel shows real-user CrUX data for LCP, INP, and CLS.
Confirm the LCP element — Chrome DevTools → Performance → record a load. The LCP marker on the Timings track names the element; check it is the image you expect.
Break down LCP — in PageSpeed Insights or WebPageTest, read the four sub-parts to find whether the loss is load delay, download, or render.
Test a fix in the lab — run Lighthouse before and after one change. Lighthouse is diagnostic, not authoritative for ranking.
Track over time — the Search Console Core Web Vitals report or the web-vitals library logging to your analytics catches field regressions early.

Field data lags 28 days, so a change you ship today shows up four weeks later in CrUX. Use the lab to confirm direction immediately.

Frequently asked questions

Does switching to AVIF improve Core Web Vitals?

AVIF improves LCP on most pages by cutting the LCP image's download time roughly in half. It does not change CLS or INP directly, though faster loads shrink the window for shift.

Can AVIF make LCP worse?

On very low-end devices, AVIF's slower decode can offset its transfer savings. This is rare on modern phones; always confirm by measuring decode on real target hardware.

Do I still need width and height with AVIF?

Yes. Width and height prevent layout shift regardless of format — AVIF carries no dimension hint that the browser uses for box reservation before download.

Should I preload every AVIF image?

No. Preload only the single LCP image. Preloading below-the-fold images steals bandwidth from the hero and can worsen LCP.

Is Lighthouse enough to pass Core Web Vitals?

No. Lighthouse is lab data and does not affect ranking. The assessment uses field CrUX data at the 75th percentile, visible in PageSpeed Insights and Search Console.

Where to go next

AVIF Optimisation — the broader performance picture
AVIF Lazy Loading — what to lazy-load and what never to
AVIF Compression Settings — encoder tuning for the size/decode balance
Image SEO Best Practices — the SEO companion to performance
Convert now: Convert JPG to AVIF, Convert PNG to AVIF