Why Your Hero Image Is Costing You Core Web Vitals Points
On most landing pages the hero image is the element Core Web Vitals actually measures. This breaks down why it fails LCP and CLS, which format to serve, and the four fixes that move a page back into the green.
The hero image is the LCP element on most pages.
On the vast majority of pages I audit, the hero image is what Largest Contentful Paint clocks. According to the 2025 Web Almanac, an image is the LCP element on 85% of desktop pages and 76% of mobile pages. So when that hero is oversized, served as JPEG, lazy-loaded, or missing dimensions, the page almost always fails Core Web Vitals and those are two hours of work most teams skip.
Why does the hero image control your LCP score?
LCP fails when the browser can't download, decode, and render the largest visible element fast enough. Google's thresholds:
- Good: under 2.5 seconds
- Needs improvement: 2.5 to 4 seconds
- Poor: over 4 seconds
Google grades at the 75th percentile of real visits.
Finding out if the hero is your LCP element
Run the page through PageSpeed Insights or open the Performance panel in Chrome DevTools and record a load. Both name the exact LCP element. If it points at the hero <img>, every byte and every millisecond of delay on that file is your LCP score.
Check mobile too. I consistently find desktop LCP looks acceptable while mobile is failing. Same hero, downloaded over a phone connection at full desktop dimensions.
Why hero images fail LCP
- The file is too big. A 1.5 MB JPEG hero is common and almost always avoidable.
- Wrong format. JPEG where AVIF would be half the size at the same visual quality.
- It's lazy-loaded.
loading="lazy"on the hero tells the browser to wait. - No priority hint. Without
fetchpriority="high", the browser treats the hero the same as the analytics script and they compete for bandwidth. - Late discovery. If the image URL lives in a CSS file or gets injected by JavaScript, the browser finds it after parsing the body. By then, the LCP clock is already ticking.
- No
srcset. Mobile downloads the full desktop image.
Which format to use
Serve AVIF first, with WebP and JPEG fallbacks via the <picture> element. AVIF covers roughly 93–95% of users in 2026 per caniuse.com, and the fallback handles everything else cleanly.
| Format | Typical size vs JPEG | Browser support (2026) | Role |
|---|---|---|---|
| JPEG | baseline | ~100% | last-resort fallback |
| WebP | 25–35% smaller | ~97% | safe default |
| AVIF | ~50% smaller | ~93–95% | best option, needs fallback |
AVIF conversion is a one-afternoon job and I have never seen a production site where the browser support numbers were a legitimate reason to skip it. The <picture> element exists precisely to handle this. If you're still serving JPEG heroes in 2026, you're paying double the download time for the same visual quality.
Pixel Wand handles this automatically: upload once and it generates AVIF and WebP variants alongside the JPEG fallback, dimensions preserved.
The actual fixes
<picture>
<source srcset="/hero.avif" type="image/avif" />
<source srcset="/hero.webp" type="image/webp" />
<img
src="/hero.jpg"
alt="Product dashboard on a laptop"
width="1600"
height="900"
fetchpriority="high"
/>
</picture>
Convert to AVIF with a fallback. Half the bytes means roughly half the download time for LCP.
Add fetchpriority="high". The Google Flights team added it to their hero image and saw LCP improve by 700 milliseconds — the single biggest gain in their entire performance sprint. Despite that, the 2025 Web Almanac found only 17% of pages set it on their LCP image.
Remove loading="lazy" from the hero. Lazy loading is for below-the-fold images. On the LCP element it adds delay with no upside. I see this constantly on sites using image optimization plugins that apply lazy globally without excluding the first image.
Set width and height. These reserve the layout box so the page doesn't shift when the image loads, which also helps CLS.
If the hero still loads late after those changes, add a preload in the <head>:
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">
This starts the download before the browser finishes parsing the body.
CLS and the missing dimensions
A hero with no width and height is the most reliable way to fail CLS: the browser reserves no space, lays out the text below, then shoves everything down when the image arrives.
FAQ
Should I ever lazy-load my hero image?
No. The hero is already in the viewport, so loading="lazy" only delays the download.
How small should a hero image be?
For a full-width hero, under 150–200 KB is the target. AVIF makes that realistic at full quality for most photographic content. If your hero is over 500 KB, cut it before touching format. I've seen teams spend days chasing AVIF tooling configuration while sitting on a 900 KB source file they never compressed. Start with the file size, then worry about format.
Will AVIF break older browsers?
Not if you use <picture> with WebP and JPEG fallbacks; browsers that don't support AVIF fall through to the next format they support automatically.
Run PageSpeed Insights on your top landing page, confirm the hero is the LCP element, and work through the list above. AVIF conversion and fetchpriority="high" together move most sites I've worked on out of "needs improvement" and into a passing score.