Why LCP is still the Core Web Vital most sites get wrong in 2026

For the last two years, every performance conversation with a new client has started the same way: "we heard we need to fix INP." Interaction to Next Paint earned its reputation fair and square when it replaced First Input Delay as an official Core Web Vital back in 2024. But when we pull the actual pass-rate numbers in 2026, INP is quietly the metric sites are getting right — and Largest Contentful Paint is the one still dragging scores down.

The May 2026 numbers tell a different story than the panic

According to the Chrome UX Report's May 2026 release (published June 9, 2026, covering more than 18 million origins), 86.6% of sites post a "good" INP score and 81.3% post a "good" CLS score. LCP lags well behind both at 68.6%. Put all three together and only 55.9% of origins pass Core Web Vitals overall — and the gap is worse on mobile, where the combined pass rate drops to 48%, versus 56% on desktop. INP was never the sites' real problem. LCP still is.

The reason is almost always the same image

The HTTP Archive's 2025 Web Almanac found that on mobile pages, 73% of LCP elements are images — usually the hero photo or banner at the top of the page. The same report found that 16% of mobile sites accidentally lazy-load that exact image, which is close to the worst thing you can do to it: lazy-loading defers the browser's request until it's already scrolled into view, which is precisely the delay LCP is measuring. We've opened client sites where the developer had applied `loading="lazy"` to every `<img>` tag sitewide as a blanket "performance fix," including the one image the whole metric depends on.

What we check first on every new client site

Before we talk to a client about redesigning anything, we open DevTools and answer three questions about their current homepage:

• What element is Chrome flagging as the LCP candidate? Usually visible in the Performance panel or a Lighthouse trace — and it's rarely what the client would guess.
• Is that element lazy-loaded, sized in CSS instead of at the file level, or hidden behind a web font swap? Any one of the three adds real, measurable seconds.
• Is it preloaded? A `<link rel="preload">` on the hero image, paired with `fetchpriority="high"`, tells the browser to fetch it before it finishes parsing the rest of the head — often the single highest-leverage change available.

This is the same first pass we described when we audited 12 client sites last year, just aimed specifically at the metric everyone assumes is already fine.

Fixing it rarely means a rebuild

On most sites we touch, correcting LCP is a same-day fix: remove the lazy-load attribute from the hero image, add a preload hint, and serve it in a modern format at the actual render size instead of a 3,000px camera original. None of that requires new code architecture. It requires someone to actually check which element is being measured, instead of assuming a general "make it faster" pass already covered it.

If your last speed fix focused on interactivity and you haven't checked your LCP element specifically, that's usually where the remaining points are hiding. It's a fifteen-minute check we run as the first step of our web design and build service, before we recommend touching anything else.