You added loading="lazy" to every image on the page because some performance guide told you to. Now your Largest Contentful Paint is 4.2 seconds and you can't figure out why.
The problem is simple: lazy loading tells the browser "don't fetch this until it's near the viewport." For images below the fold, that's smart. For your hero image, the one that determines your LCP score, it's the opposite of smart. You're telling the browser to deprioritize the single most important visual element on your page.
What LCP actually measures
Largest Contentful Paint marks the moment the biggest visible element finishes rendering. On most pages, that's a hero image, a banner, or a large background photo. Google's threshold: under 2.5 seconds is good, over 4 seconds is poor.
The browser's loading pipeline works in stages. It discovers images by parsing HTML, then assigns fetch priority based on position, attributes, and heuristics. When you slap loading="lazy" on the hero, you push it to the back of the queue. The browser fetches fonts, stylesheets, and below-fold assets first. Your hero image sits in a holding pattern until the browser calculates that it's near the viewport, which can't happen until layout is complete.
The fetchpriority fix
HTML now has a fetchpriority attribute. Set fetchpriority="high" on your LCP image and the browser moves it to the front of the fetch queue:
<img src="hero.webp" fetchpriority="high" width="1600" height="900" alt="...">
This does two things: it tells the browser to start fetching immediately (no lazy gate), and it bumps the priority above other images that are merely eager-loaded.
Chrome's implementation shipped in version 101. Safari added support in 17.2. Firefox has it behind a flag as of early 2025. For browsers that don't support it, the attribute is ignored and you get normal eager loading, which is still better than lazy for your hero.
Common LCP image mistakes
Wrong format. A 2MB JPEG hero image will always have poor LCP. Convert to WebP (25-35% smaller than JPEG at equivalent quality) or AVIF (40-50% smaller). Use the <picture> element for format negotiation:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" fetchpriority="high" width="1600" height="900" alt="...">
</picture>
Missing dimensions. Without explicit width and height, the browser can't reserve space during layout. That delays the LCP calculation because layout shift detection runs first.
CSS background images. If your hero is a background-image in CSS, the browser can't discover it until the stylesheet is parsed and CSSOM is built. That adds a full round trip. Move critical hero images into HTML <img> tags where the preload scanner can find them during HTML parsing.
Preload without fetchpriority. Adding <link rel="preload" as="image" href="hero.webp"> helps discovery but doesn't change priority. Combine preload with fetchpriority="high" on the actual <img> element for maximum effect.
What the tool checks
The LCP Image Candidate Audit scans your page for above-the-fold images and flags:
- Images with
loading="lazy"that are likely LCP candidates - Missing
fetchpriorityon hero images - Oversized images (natural dimensions much larger than displayed)
- Images served as JPEG/PNG where WebP/AVIF would be significantly smaller
- CSS background images used for primary visual content
- Missing width/height attributes on above-fold images
The tool generates a fix prompt you can hand to your developer or AI assistant with specific remediation steps for each finding.
The numbers behind it
According to the HTTP Archive's 2024 Web Almanac, the median LCP on mobile is 3.4 seconds. Over 40% of origins fail the 2.5-second "good" threshold. Image-related issues are the single largest contributor to poor LCP scores, ahead of both server response time and render-blocking resources.
Google's own documentation states that LCP is the Core Web Vital most strongly correlated with user-perceived page speed. It's also the one most commonly failed. The gap between lab scores (Lighthouse) and field scores (CrUX) is widest for LCP because lab tests don't simulate real-world network variability.
If you're building a site that needs to earn its own traffic, the image loading chain is where most of your performance budget lives. My book The $97 Launch ($9.99 on Kindle) walks through the full technical checklist for sites that can't afford to lose organic visitors to slow load times.
Fact-check notes and sources
- LCP threshold of 2.5s: web.dev Core Web Vitals
- fetchpriority browser support: Can I Use fetchpriority, Chrome 101+, Safari 17.2+
- WebP compression savings (25-35%): Google Developers WebP study
- HTTP Archive median LCP: 2024 Web Almanac, Performance chapter
- Preload scanner behavior: web.dev Preload Scanner
Related reading
- Your Lighthouse score is lying to you — lab vs field performance data
- Critical CSS extraction and FCP — render-blocking stylesheet fixes
- Font loading strategy — font swap and display patterns
- Responsive image srcset audit — serving right-sized images
- Render-blocking resource audit — finding what blocks first paint
This post is informational, not SEO-consulting advice. Tool mentions are descriptive. No affiliation with browser vendors is implied.
