Should you lazy-load your homepage hero image? In most cases, no, and the reasoning comes straight from how browsers measure the Largest Contentful Paint. If that image is visible the moment the page opens, deferring its request usually delays the exact resource the LCP timer is watching. This guide walks through confirming which element is actually your LCP candidate, checking whether your theme is quietly lazy-loading it anyway, comparing that loading behavior against the file’s actual weight, and matching the fix, eager loading, a fetch-priority hint, or compression, to whichever bottleneck you find rather than guessing.
Table of Contents
Should You Lazy-Load a Hero Image? The Above-the-Fold Rule
Should you lazy-load a hero image that fills the top of your homepage before anyone scrolls? In most cases, no. Google Search Central’s lazy-loading documentation advises against deferring content that is likely to be immediately visible when the page loads, and Chrome’s request-discovery guidance for the Largest Contentful Paint metric specifically warns against setting loading="lazy" on the element that turns out to be the page’s LCP candidate. A lazy-loaded image waits for a script or an intersection observer to fire before the browser even requests the file, and that delay lands directly inside the LCP timer.
The exception matters just as much as the rule. “Hero” is a design label, not proof that an image is the Largest Contentful Paint element. On a template with a tall navigation bar, a large headline, or a hero pattern that swaps in a static image only on some breakpoints, the labeled hero graphic might not be the largest element painting inside the initial viewport at all. Viewport size changes the picture too: content that fills a phone screen can sit comfortably below the fold on a wide desktop monitor. Before changing any loading attribute, check how the hero renders across common breakpoints with a Screen Resolution Test, then confirm separately which element actually gets reported as LCP at each size.
Confirm the Actual LCP Element in PageSpeed Insights
Guessing at the LCP element wastes effort on the wrong fix. Run the homepage through PageSpeed Insights and look at the reported Largest Contentful Paint entry, which names the specific element that was measured rather than only a numeric score. Test mobile and desktop separately, since responsive themes frequently serve a different hero crop, a different aspect ratio, or an entirely different image source per breakpoint, and the LCP element can differ between the two results.
PageSpeed Insights version 5 combines a simulated Lighthouse lab test, useful for diagnosing exactly what is happening on the page you just ran, with Chrome User Experience Report field data drawn from real visits over the preceding 28 days when enough traffic exists. The lab run and the field data can disagree, so treat the lab result as your current diagnostic view and the field data as a rolling picture of what visitors already experienced. If the named LCP element is your hero image in either view, the loading-behavior and file-size checks below apply directly to that file.
Check the Hero Image's Loading Behavior
Open View Page Source on the homepage and search the hero <img> tag for three signals: a loading="lazy" attribute, a real src or srcset pointing at an actual file, or a JavaScript placeholder pattern such as data-src used by many lazy-loading scripts. Source HTML only shows what the server originally sent, though, not what a theme’s script changes after the page finishes loading.
Open the browser’s developer tools, switch to the rendered Elements panel, and inspect the same tag again to see whatever attributes a script added or removed at runtime. Then check the Network waterfall to see when the request for that file actually fired relative to the document and other resources; a hero request that starts noticeably late points to a loading-behavior problem rather than a file-weight problem. If loading="lazy" is present on a hero image that is visible without scrolling, either remove the attribute, since omitting it already gives normal eager behavior, or set it explicitly:
<img src="/images/hero.jpg" loading="eager" alt="Homepage hero">
Check the Hero Image's File Size and Dimensions
Loading behavior and file weight are separate problems, and solving one does not automatically solve the other. Run the homepage through Page Size Checker to see the hero image’s own transferred size next to total page weight. A hero that downloads quickly in isolation can still delay LCP if its request starts late, and a hero requested right away can still be slow to paint if the file itself is heavy.
Compare the file’s actual pixel dimensions against the space it renders at on the page. A hero uploaded at full camera resolution and then scaled down purely with CSS forces every visitor to download far more data than the layout needs. Chrome’s LCP breakdown documentation splits image LCP timing into time to first byte, resource load delay, resource load duration, and element render delay, so note which phase is longest for your hero before choosing a fix: a long load delay points back toward loading behavior, while a long load duration points toward file weight.
Should You Lazy-Load the Hero Image or Fix Something Else?
Match the fix to whichever phase is actually slow rather than applying every technique at once. If discovery is late because the image is referenced through a CSS background or injected by JavaScript, an early preload for that specific file can help the browser start the request sooner, though you still need to match the responsive variant carefully so you are not preloading an image the browser will not use. If the request starts on time but competes with other resources for bandwidth, test fetchpriority="high" on that one image:
<img src="/images/hero.jpg" fetchpriority="high" alt="Homepage hero">
Fetch priority is a hint to the browser, not a guarantee, and it does not cancel lazy-loading behavior: an image marked both loading="lazy" and fetchpriority="high" still waits until it scrolls near the viewport before the browser requests it. Avoid marking many images high priority, since spreading the hint around removes its usefulness.
If the load duration itself is the long phase, a smaller file can shorten download time. Image Compressor compresses JPG, PNG and WebP images, so use it to reduce the hero’s file size and compare visual quality against the bytes saved. It does not resize an image to its rendered dimensions, create srcset variants or choose a format for you; those steps happen in your image editor, build process or CMS. Compression alone will not fix a late-discovered or render-blocked request either. So, should you lazy load hero image files at all, or fix the loading behavior instead? Retest the resulting file and the full page afterward using both the lab run and later field data, since Google’s published good-LCP target sits within 2.5 seconds of page load measured at the 75th percentile, and Core Web Vitals feed into Google’s ranking systems without guaranteeing any specific ranking or traffic outcome.
Frequently asked questions
What does loading="lazy" actually do to an image?
It tells a compliant browser to defer requesting that image until it is near the viewport, instead of requesting it as soon as the browser parses the tag, following the browser-level lazy-loading behavior described in current web performance documentation.
Is a hero image automatically the LCP element?
Not necessarily. “Hero” describes a design pattern, not a measured outcome. Confirm the actual Largest Contentful Paint element for both mobile and desktop with PageSpeed Insights before assuming the labeled hero is what search engines and browsers are timing.
Can fetchpriority="high" cancel out loading="lazy" on the same image?
No. Fetch priority only changes how urgently an already-scheduled request is treated. An image still marked loading=”lazy” remains deferred until it scrolls near the viewport regardless of any priority hint applied to it.
Will compressing the hero image fix a slow LCP score by itself?
Sometimes it shortens the download phase, but a heavy file is only one possible cause among several. If the request starts late or the server response itself is slow, compression alone will not close that gap, so retest afterward to see which phase actually improved.
Why does PageSpeed Insights sometimes show different results between visits?
The lab test simulates a single run under set conditions, while any available field data reflects an aggregate of real visits collected over the preceding 28 days. Both are valid, but they measure different things and can legitimately disagree.
Should every below-the-fold homepage image stay lazy-loaded?
Generally yes. Images that are not visible without scrolling are reasonable candidates for lazy loading, since deferring their request does not affect what paints during the initial view of the page.
How do I check whether my theme is silently adding lazy loading to the hero image?
View the page source for a loading or data-src style attribute, then confirm in the browser’s rendered Elements panel and Network tab, since theme scripts can add or remove loading behavior after the initial HTML has already been sent.
Next steps
Should you lazy load hero image content on your homepage? Only if that image sits below the initial viewport once you have actually checked. Confirm the true LCP element in PageSpeed Insights first, then inspect its request timing and its file weight as two separate questions before touching any loading attribute. Fix loading behavior with an eager attribute or a careful fetch-priority hint when discovery is the bottleneck, and fix the bytes with proper sizing and compression when weight is the bottleneck. Retest both the lab result and the field data afterward, since a single change rarely improves both phases at once.
Related tools and resources on AllEasySEO:
Sources and further reading
- https://developers.google.com/search/docs/appearance/core-web-vitals
- https://web.dev/articles/fetch-priority
- https://web.dev/articles/optimize-lcp?authuser=993749347
- https://web.dev/articles/browser-level-image-lazy-loading?authuser=6
- https://developers.google.com/speed/docs/insights/v5/about?authuser=2&hl=en
- https://web.dev/articles/compress-images
- https://developer.chrome.com/docs/performance/insights/lcp-breakdown?authuser=2
- https://web.dev/articles/optimize-css-background-images-with-media-queries
- https://web.dev/learn/performance/image-performance
- https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading
Comments