Fixing Image-Related Core Web Vitals Issues Without a Full Site Rebuild

Your Core Web Vitals report is flagging poor LCP, and you already suspect the hero image. You’re probably right. Largest Contentful Paint is measured from the moment a user lands on your page to the moment the biggest visible element fully renders. On most sites, that element is a large photo, a banner, or a featured image sitting above the fold. If that asset is heavy, overscaled, or saved in the wrong format, LCP takes the hit directly, and no amount of caching or CDN tuning will fully compensate.

The format you choose for hero images can cut LCP times more than almost any other single change.

– AVIF files are typically 30 to 50 percent smaller than equivalent WebP files at the same perceptual quality

– Converting existing JPEGs to AVIF requires no site rebuild, just re-exporting your assets

– Pairing format conversion with correct dimension planning removes two of the most common bottlenecks at once

Why LCP Scores Collapse Around Hero Images

Understanding how LCP is scored helps clarify why images are so often the root cause. Google classifies anything above 4.0 seconds as “Poor,” and most image-heavy sites sitting in that range share the same pattern: the hero image is doing too much work.

Here’s what’s happening under the hood. The browser downloads the HTML, parses it, discovers the image source, makes a network request, receives the file, decodes it, and then paints it to screen. Every byte in that file adds cost at the decode step. If the image is also the wrong size for the viewport, the browser has to rescale it after decoding, adding yet another layer of work.

Neither of these problems requires a site rebuild to fix.

The Format Gap Most Teams Overlook

Many teams upgraded from JPEG to WebP a few years ago and considered the job done. WebP was a real improvement. But AVIF has since pulled ahead considerably. At comparable perceptual quality, AVIF files tend to be 30 to 50 percent smaller than WebP, and browsers covering the vast majority of global traffic now support it natively.

The bottleneck is rarely browser support at this point. It’s the conversion step. Teams often skip AVIF because the tooling feels unfamiliar, or because they assume the encoder will change how images look. A good converter handles this cleanly. Using a JPG to AVIF tool lets you compare the output side by side before committing, so there’s no guesswork about whether quality holds up under compression.

AVIF encoding uses more CPU than WebP or JPEG, but that cost lands on your machine during export, not on the user’s device at load time. The user only downloads the finished, compressed file.

What Is Actually Making Your Images Slow

Before converting anything, it helps to understand which part of your image pipeline is the real culprit. There are usually three overlapping problems:

• File format. JPEG and PNG carry significant overhead compared to modern formats. AVIF is the most efficient option widely available right now.
• File size. Even within the same format, encoding quality settings vary widely. High-quality exports with no compression applied can be many times larger than they need to be.
• Dimensions. A 4000px wide image served to a 390px mobile screen is decoded at full resolution before CSS resizes it. The browser does the heavy lifting, but it still pays the cost in time.

Fixing the format handles the first two. The third problem needs a separate step.

Planning Dimensions Before You Convert

This is the step most developers skip, and it’s the one that causes the most hidden overhead. Serving an oversized image doesn’t just waste bandwidth. It forces the browser to decode more pixel data than it will ever display, which adds rendering time even when the file itself is not particularly large in kilobytes.

Before converting any image, calculate the exact pixel dimensions you need for each breakpoint. What width does the hero slot occupy at 1280px viewport? At 768px? At 390px? The answers aren’t always obvious, especially when CSS uses percentage widths or max-width constraints that vary by container.

An aspect ratio calculator is genuinely useful here because it lets you input your source dimensions and target width, then returns the correct height without distorting the crop. That matters for hero images, where a small dimension mistake creates either black bars or an awkward center crop at certain viewport sizes.

Once you know the exact dimensions needed at each breakpoint, you resize the source before encoding. The AVIF file you produce is already the right size. No upscaling risk, no unnecessary pixel data baked into the file.

A Practical Order of Operations for LCP Image Fixes

If you’re working through a backlog of underperforming pages, this order tends to produce the fastest results:

1. Identify the LCP element on each page using Lighthouse or PageSpeed Insights. Confirm it’s an image, not a block of text or a background gradient.
2. Measure the rendered width of that element at your main breakpoints using browser DevTools in responsive mode.
3. Calculate the exact pixel dimensions you need based on the original image’s aspect ratio. Avoid rounding up aggressively, because extra pixels cost you at decode time.
4. Resize the source image to match each set of dimensions before exporting. Never scale up, only down.
5. Convert to AVIF and review the output quality carefully. Focus on fine text, smooth gradients, and high-contrast edges, which are the areas most likely to show encoding artefacts.
6. Implement with a srcset attribute so each breakpoint receives the appropriate file. Pair this with the correct sizes attribute so the browser can choose the right source before it renders.
7. Re-run PageSpeed Insights and compare the LCP number. For most sites with large hero images, this sequence moves the needle measurably.

Encoding Quality Settings Worth Knowing

AVIF quality is expressed on a scale from 0 to 63 in most encoders, where lower numbers mean higher quality. That’s inverted from how most people expect it to work, so it’s worth understanding before you start batch exporting assets.

For hero images, a quality setting around 30 to 45 usually hits the right balance between file size and visual fidelity. Below 25, you may see banding in smooth gradients. Above 50, the file size savings diminish past the point of practical usefulness.

A few things to check when reviewing AVIF exports:

• Flat colour regions, like white backgrounds or solid overlays, encode very cleanly at most quality settings
• Faces and skin tones hold up well at moderate compression, but check them at 1x zoom rather than zoomed out
• Photographic noise and film grain can look smudgy at high compression levels, so use slightly higher quality settings for textured images

Browser Support and How to Handle Fallbacks

AVIF is supported in Chrome, Edge, Firefox, and Safari on iOS 16 and later. That covers the clear majority of users for most sites in 2026. For the remainder, a WebP fallback handles older Safari versions, and a JPEG fallback covers anything older still.

The standard implementation uses the picture element with multiple source types. Your CMS or build pipeline should handle this automatically if you’re already using responsive image tooling. If you’re working manually or on a static site, adding AVIF as the first source type takes about five minutes per template.

The fallback chain costs modern browsers nothing. They read the first matching source and ignore the rest.

When LCP Is Still Slow After Format Changes

If you’ve converted to AVIF and the LCP number hasn’t improved as expected, check these three areas before assuming the format change didn’t work.

First, check whether the image is being preloaded. If the browser only discovers the hero image after parsing CSS and finishing layout, there’s a delay regardless of file size. Adding a preload hint in the document head tells the browser to start fetching the image earlier in the process.

Second, confirm the image is not being lazy-loaded. Lazy loading is genuinely valuable for images below the fold, but applying it to LCP elements delays the exact thing you’re trying to speed up. The hero image should never carry a lazy loading attribute.

Third, check your CDN and server configuration. AVIF files need to be served with the correct MIME type. Some origin servers don’t recognise it and either serve the file incorrectly or fall back to JPEG delivery, which defeats the entire exercise.

The Case for Fixing This at the Asset Level

The real appeal of addressing LCP at the image level is that the scope stays manageable. You’re not refactoring rendering architecture or migrating your CMS. You’re changing the format and dimensions of your images and updating how they’re referenced in markup.

For most sites with hero image LCP problems, this combination produces improvements that show up in field data within a few weeks, once the new real-user measurements roll in. The work is contained, testing is straightforward, and results are measurable against a clear baseline.

Start with your highest-traffic pages. Fix the LCP image on each one. Run the numbers again. The improvements compound quickly when you’re addressing the right bottleneck from the start.