Images and Core Web Vitals: fix the biggest LCP cost first

By the SnapTools editor·October 2026·7 min read

Google's May 2026 algorithm update put additional ranking weight on LCP — Largest Contentful Paint, the moment the main content of a page becomes visible. On the overwhelming majority of content pages, the LCP element is an image: the hero photo, the product shot, the banner. Which means for most sites, the single most effective performance fix is not JavaScript surgery or a faster host. It is shipping a properly sized, properly compressed hero image.

What LCP actually measures

LCP is the time until the largest visible element finishes painting, counted from when the user first navigates to the page. Google classes 2.5 seconds or better as "good" and anything past 4 seconds as "poor", measured at the 75th percentile of real users. Unlike older metrics, it reflects what a visitor actually experiences: a page can be technically "loaded" while the user is still staring at a blank rectangle where the hero image should be.

Images dominate LCP for a simple reason: they are usually the heaviest single resource on the page, and the browser cannot paint the element until the image has downloaded and decoded. A 3 MB hero photo on a mid-range phone connection can consume the entire "good" budget on its own.

The checklist, in order of impact

1. Right-size the dimensions. A hero displayed at 1200 pixels wide does not need a 4000-pixel original. Serving pixels nobody can display is the most common and most expensive mistake — often 5–10× more bytes than necessary.
2. Use WebP. At quality 75–80 it is typically 25–34% smaller than the equivalent JPG, with support on around 97% of browsers in 2026. The bytes you save go straight into the LCP budget.
3. Never lazy-load the LCP image. This one surprises people: adding loading="lazy" to the hero image hurts the metric, because the browser delays fetching exactly the resource it needs first. Lazy-load everything below the fold; exclude the hero.
4. Preload the hero. A <link rel="preload" as="image"> tells the browser to start fetching the hero before the layout is even computed, shaving several hundred milliseconds on image-heavy pages.
5. Compress honestly. Quality 70–80 is visually transparent on photographs for web viewing. The difference between 80 and 95 is enormous in bytes and nearly invisible on a screen.
6. Cache and CDN. Once the image is small, make sure repeat visits and distant users fetch it from a nearby edge rather than your origin.

Budgets that work in practice

Treat these as starting points, then verify with PageSpeed Insights or Chrome's DevTools Lighthouse panel on a real device profile. A hero image that passes on a fibre connection can still blow the budget on a phone over 4G.

Hitting those numbers with local tools

Everything above can be done without uploading a single image anywhere. The resizer sets exact pixel dimensions; the converter moves files to WebP; and the compressor offers two modes that matter here: a quality slider for general work, and compress to an exact file size when you want to hit "under 150 KB" as a hard budget rather than guessing. All three run in your browser — handy when the images are client work or unreleased designs that should not touch a third-party server.

A workflow that works: resize to the display width first, convert to WebP second, compress last — in that order, because shrinking dimensions before compressing lets quality stay high, which is where the real savings live.

Frequently asked questions

What is a good LCP score?

2.5 seconds or faster, measured at the 75th percentile of your real users. Between 2.5 and 4 seconds counts as "needs improvement", and beyond 4 seconds is "poor". Google's 2026 update leans harder on this boundary than earlier releases.

Is WebP enough, or should I also serve AVIF?

WebP first. It is instant to produce, universally supported, and typically 25–34% smaller than JPG. AVIF usually compresses further but is slow to encode and unsupported by in-browser tools, so treat it as an optional second pass once your pipeline is mature. See our WebP vs AVIF comparison for the details.

Does lazy loading help Core Web Vitals?

It helps overall page weight and bandwidth, and it is the right choice for images below the fold. But applying it to the LCP image backfires: the metric measures exactly that element, and lazy-loading delays it. The rule is simple — lazy-load everything except the hero.

How small should my hero image be?

Around 100–200 KB as a WebP for a typical full-width desktop hero, and under about 120 KB for the mobile variant. If you cannot get there at reasonable quality, the image is probably still too large in pixel dimensions.