Improving your LCP: complete image guide for Core Web Vitals in 2026

Understanding LCP: why your images sink you

LCP measures the time elapsed between page load start and the appearance of the largest visible element in the viewport (above the fold). In practice, in over 80% of websites, this 'largest element' is the hero image — the one that occupies most of the first screen.

Google considers your LCP as: — Good (green) if < 2.5 seconds — Needs improvement (orange) if between 2.5 and 4 seconds — Poor (red) if > 4 seconds

A poor LCP signals to Google that your page takes too long to deliver its main content, degrading your SEO ranking and increasing your bounce rate. A Google study on 2.5 million sites in 2024 showed sites with LCP < 2.5s have a conversion rate 24% higher than those with LCP > 4s.

The two main causes of poor LCP: (1) too heavy a hero image that takes time to arrive from the server, (2) an image at raw size (4000 × 3000) re-displayed in a banner of 1200 × 600 — the browser must download and decode an image 10 times too big.

Step 1 — Measure your real LCP (not synthetic)

Before optimizing, you need to know what your real users experience. Two complementary tools:

Google PageSpeed Insights (pagespeed.web.dev): enter your URL and get a complete audit in 30 seconds. It provides two metrics: 'Field Data' (the real LCP of your real visitors over the last 28 days, based on the Chrome User Experience Report) and 'Lab Data' (a simulated lab test). Field Data is what counts for SEO, that's what Google uses.

Vercel Speed Insights (if you're hosted on Vercel): integrated in the dashboard, displays median LCP and p75 per route and per device, real-time update. Indispensable to spot a perf change after a code update.

Chrome DevTools (Performance tab + Lighthouse): reproduces LCP in lab in your browser. Practical for iterating quickly during development, but doesn't reflect the perf of your real users on 4G.

Realistic goal for 2026: median LCP under 2 seconds in lab and under 2.5 seconds in field data. Sites in the top 10% in SEO are at 1.2-1.8 seconds on average.

Step 2 — Serve modern formats (WebP, AVIF)

JPG, despite its 30 years of existence, is no longer optimal in 2026. Modern formats weigh 30-50% less at equivalent visual quality:

— WebP (Google, 2010): 25-35% lighter than JPG. Supported by 97% of browsers in 2026 (all modern: Chrome, Firefox, Safari, Edge, Opera).

— AVIF (Alliance for Open Media, 2019): up to 50% lighter than JPG, twice as efficient as WebP. Supported by about 94% of browsers in 2026 (Chrome, Firefox, Safari since iOS 16, Edge).

The winning strategy: use the HTML <picture> tag with cascading fallback:

<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" alt="..." loading="eager" fetchpriority="high"> </picture>

The browser serves the most modern format it supports, and falls back to JPG as last resort for the very old. Our PixFlow tool offers JPG→WebP conversion (pixflow.tech/en/convert-jpg-to-webp) and JPG→AVIF (pixflow.tech/en/convert-jpg-to-avif) to prepare these 3 versions in seconds.

Step 3 — Dimension correctly (the real displayed size)

The most costly LCP mistake: serving an image at 4000 × 3000 pixels when it displays in a 1200 × 600 block on the user's screen. The browser downloads all useless pixels, takes time to decode, then throws them away on display.

The rule: generate several versions of each image at resolutions matching target screens. For a hero image, typically:

— 640 × 360 for mobile (≤ 768 px wide) — 1024 × 576 for tablet (769-1280 px) — 1920 × 1080 for desktop (≥ 1281 px) — 2560 × 1440 or 3840 × 2160 for Retina screens if you want max quality

Use the <img srcset> or <picture> tag with breakpoints to serve the right version per screen size:

<img src="hero-1024.jpg" srcset="hero-640.jpg 640w, hero-1024.jpg 1024w, hero-1920.jpg 1920w" sizes="(max-width: 768px) 640px, (max-width: 1280px) 1024px, 1920px" alt="..." loading="eager" fetchpriority="high" >

Our PixFlow tool (pixflow.tech/en/resize-image) handles batch resizing — you load the source image in 4K, generate 3-4 versions in one click.

Step 4 — Hint the browser: fetchpriority + preload

Once the image is optimized, one problem remains: the browser doesn't know this image is critical. By default, it prioritizes it as a normal image (low priority after HTML/CSS/JS). Result: your hero image waits for the rest to load, and your LCP suffers.

Two techniques to prioritize it:

fetchpriority='high' on the hero image's <img> tag. Asks the browser to download it in priority, as soon as it discovers the tag in HTML. Supported by Chrome, Edge, and Firefox since 2023, ignored without regression by Safari. It's improvement #1 for LCP in 2026.

<link rel='preload'> in the HTML <head> to force download before the browser even parses the <body>:

<head> ... <link rel="preload" as="image" href="hero-1024.webp" type="image/webp" media="(min-width: 769px) and (max-width: 1280px)"> <link rel="preload" as="image" href="hero-1920.webp" type="image/webp" media="(min-width: 1281px)"> </head>

This advanced technique saves 300-600 ms of LCP on SSR or static-generated sites. On a pure React SPA, impact is less because HTML is initially served empty.

Step 5 — Lazy load everything EXCEPT the hero image

The HTML attribute loading='lazy' tells the browser to defer image loading until it enters the viewport. It's free, natively supported by 95% of browsers in 2026 (no JS library), and frees bandwidth for critical images.

The rule: apply loading='lazy' to ALL images EXCEPT the hero image (which must load immediately for LCP). If you have a gallery of 20 photos on a page, that's 19 images saved at initial loading.

<img src="hero.webp" alt="..." loading="eager" fetchpriority="high"> <!-- HERO: eager + high priority --> <img src="gallery-1.webp" alt="..." loading="lazy"> <!-- Below the fold: lazy --> <img src="gallery-2.webp" alt="..." loading="lazy">

Frequent mistake: applying loading='lazy' to all images, including hero. Catastrophic result: the browser waits for the hero to be in viewport to load it, which can push LCP from 1.5s to 4s on mobile. Always verify your hero image is loading='eager' (or has no attribute, which is default).

Step 6 — Reserve space to avoid CLS

LCP isn't the only metric impacted by images. CLS (Cumulative Layout Shift) measures visual jumps — when an image arrives and pushes existing content. A CLS > 0.1 is considered bad.

The solution: always specify width and height on your <img> tags, even if you override them in CSS. This lets the browser reserve the exact space before loading, avoiding visual jump.

<img src="hero.webp" width="1920" height="1080" alt="..." style="width: 100%; height: auto;" <!-- responsive in CSS --> loading="eager" fetchpriority="high" >

The aspect ratio (width / height) calculated by the browser lets it reserve the right space even if you resize in CSS. Without these attributes, the browser doesn't know the space to reserve and abruptly inserts the image when it arrives, pushing content and triggering CLS.

Same rule for inline SVG images: specify width / height on the tag.