How to Optimize Images for Core Web Vitals and LCP in 2026

Image optimization for Core Web Vitals is the highest-leverage performance work most sites skip. Google measures real user experience through three metrics — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). On typical marketing pages, blogs, and storefronts, images drive at least two of those three.

The good news: you do not need a CDN rewrite engine or a six-figure image platform to pass. You need correctly sized files, modern formats, and HTML that tells the browser which image matters most. Asset Melt handles the prepare locally step — compress hero images, batch-export AVIF and WebP variants, and hit size budgets before anything hits your CMS.

Why images dominate Core Web Vitals

HTTP Archive data consistently shows images as 45–55% of page weight. That alone would matter for mobile data plans. For SEO, the sharper problem is LCP: on most pages, the LCP element is a hero <img>, a background image, or a large product photo.

When that resource is a 2.4 MB camera JPEG displayed at 800 CSS pixels, the browser still downloads the full file before LCP can fire. PageSpeed Insights flags "properly size images" and "serve images in next-gen formats" because those audits map directly to LCP failures.

Core Web Vitals will not rescue thin content. They do matter when you compete on similar keywords — a faster page with the same intent wins the experience tiebreaker Google describes in its page quality documentation.

Step 1: Shrink the LCP image at the source

Before touching HTML, fix the file. A repeatable LCP image optimization workflow:

1. Identify the LCP candidate — usually the hero above the fold, not your logo favicon.
2. Resize to display size — export at 1.5–2× the CSS width, not full 12 MP camera resolution. A 1200–1920px long edge covers most hero layouts.
3. Encode AVIF and WebP — AVIF first for minimum bytes; WebP as fallback. Keep a MozJPEG at quality 82–88 for RSS and legacy embeds.
4. Set a size budget — if your hero must stay under 150 KB for mobile LCP, use size-budget mode instead of guessing quality sliders.

Open the AVIF compressor for a single hero, or the batch image compressor when a landing page refresh ships a dozen assets at once. Everything runs in the browser — no upload queue, no vendor retention policy to trust.

Target sizes that work in practice

These are starting points, not laws. Always verify in Lighthouse on mobile throttling:

• Full-width hero (photography): AVIF 120–180 KB at 1920px max width
• Open Graph / social card: under 200 KB at exactly 1200×630
• Blog header inline image: WebP or AVIF 80–150 KB at 1200px width
• Product grid thumbnail: WebP 40–80 KB at 800px max width

If AVIF encoding time blocks your deadline, ship WebP first tonight and queue AVIF overnight. WebP alone often cuts JPEG size by 30–50% — enough to move LCP from "needs improvement" to "good" on many pages.

Step 2: Mark up the hero for the browser

Bytes are half the battle. The other half is resource priority and responsive delivery.

Use a <picture> fallback chain

Browsers pick the first <source> they understand. Put AVIF first, then WebP, then JPEG:

<picture>
  <source srcset="/images/hero.avif" type="image/avif" />
  <source srcset="/images/hero.webp" type="image/webp" />
  <img
    src="/images/hero.jpg"
    alt="Asset Melt studio compressing images locally"
    width="1200"
    height="630"
    fetchpriority="high"
  />
</picture>

Always include type on each <source>. Without it, browsers may download the wrong variant and waste the bytes you saved.

Always set explicit width and height on the <img>. That reserves layout space and protects CLS — a separate Core Web Vitals metric that image-only LCP fixes do not address.

For a deeper format comparison, read AVIF vs WebP in 2026.

Add responsive srcset when the layout changes

A single 1920px file served to a 390px phone wastes bandwidth. Pair srcset with a accurate sizes attribute:

<img
  src="/images/hero-800.jpg"
  srcset="
    /images/hero-800.avif 800w,
    /images/hero-1200.avif 1200w,
    /images/hero-1920.avif 1920w
  "
  sizes="(min-width: 1024px) 1200px, 100vw"
  alt="Description"
  width="1200"
  height="630"
  fetchpriority="high"
/>

Export each width from the same master in Asset Melt with a max-dimension preset. Consistent encode settings across breakpoints prevent one variant from looking softer than another.

Priority and lazy loading rules

These mistakes show up in almost every PageSpeed audit:

Never lazy-load your LCP element. Chrome UX Report analyses consistently show slower LCP when the largest image is lazy-loaded. Below-the-fold images are the opposite — lazy-load them aggressively.

Step 3: Batch-optimize the rest of the page

Hero fixes move the headline metric. Page weight still comes from every other image — author avatars, feature screenshots, product grids, markdown content assets.

A pre-deploy checklist for content teams:

1. Drop the entire public/images/ or assets/ folder into Asset Melt.
2. Apply the Web Optimized preset (WebP, 1920px max) for general content.
3. Switch to AVIF for above-the-fold heroes and OG images only.
4. Export as ZIP and replace files in your repo or CMS media library.
5. Commit — smaller git LFS bills and faster preview deploys.

For WordPress, Shopify, or Webflow uploads, this workflow avoids relying on the platform to guess quality after you already stored oversized originals. You bring finished files; the CMS stores finished files.

Common Core Web Vitals image mistakes

Even experienced teams hit these:

1. Optimizing the wrong element — shrinking footer icons while the 3 MB hero stays untouched.
2. Serving 4K images in 800px containers — resize to actual display dimensions before encode.
3. Double compression — WhatsApp → CMS → "optimizer" stacks artifacts without shrinking much further. Start from the best source.
4. WebP before AVIF in <picture> — order matters; AVIF must come first.
5. srcset without sizes — the browser defaults to 100vw and may pick an oversized file.
6. Trusting CMS auto-crop alone — cropping without re-encoding leaves bloated JPEGs at new dimensions.

Measure what actually changed

Deploy, then verify with tools — not gut feel:

1. PageSpeed Insights — check mobile LCP and the "Largest Contentful Paint element" diagnostic.
2. Lighthouse — compare transferred bytes on the LCP request before and after.
3. Chrome DevTools → Network — confirm AVIF serves to supporting browsers (Content-Type: image/avif).
4. Search Console → Core Web Vitals — watch the 28-day CrUX window after real traffic hits the new assets.

If LCP does not improve after aggressive image compression, the LCP element may not be an image — inspect the PageSpeed element selector. Text-block LCP needs font and server fixes, not AVIF exports.

What "good" looks like in 2026

Google's public thresholds at the 75th percentile of real users:

• LCP: 2.5 seconds or less (good)
• INP: 200 ms or less (good)
• CLS: 0.1 or less (good)

Image work primarily moves LCP and CLS. Expect proportional LCP gains when you halve the hero file size — a 900 KB JPEG becoming a 140 KB AVIF often saves hundreds of milliseconds on mobile networks.

Local compression and privacy still matter

Performance teams sometimes route all images through cloud CDNs with on-the-fly transforms. That works at scale, but it is overkill for a marketing deploy or a blog post refresh — and it sends unreleased screenshots through a third party.

Browser-based compression keeps the Core Web Vitals prep step aligned with privacy: NDA client work, unreleased product shots, and internal docs benefit from the same LCP byte savings without an upload step. Asset Melt uses the same WASM codec family as Google Squoosh — see our Squoosh alternative guide for the full comparison.

Getting started today

1. Run PageSpeed Insights on your homepage and note the LCP element URL.
2. Download that source file (or locate it in your repo).
3. Re-encode as AVIF + WebP with a 1920px max width and a 150–200 KB budget.
4. Update <picture> markup with fetchpriority="high" and explicit dimensions.
5. Batch-process remaining page images before the next deploy.

Related reading: How to compress images in the browser, HEIC to JPG without uploading, and AVIF vs WebP in 2026.