LCP Image Fixes: fetchpriority, Preload and Lazy Load

When the biggest image on a page arrives late, visitors stare at an empty hero area and your Largest Contentful Paint (LCP) suffers. The cause is rarely the image file alone. More often the browser discovers it late, fetches it at a low priority, or is told by your markup to wait. The short answer: make the LCP image discoverable in the initial HTML, never lazy-load it, mark it fetchpriority="high" when it is the likely LCP element, and check that nothing blocks it from painting once it arrives.

This guide is for developers, SEOs and site owners dealing with a slow hero, product or cover image. It begins with the four parts that make up LCP and then shows how to identify the real LCP element. It explains when fetchpriority and preload actually help, why lazy-loading hero images backfires, and how to verify a fix. None of this promises a ranking result. The measurable goal is that real visitors see the main content sooner.

Four Parts of LCP

LCP is one number built from four sequential phases. A fix aimed at the wrong phase barely moves it. The web.dev Optimize LCP guide (Opens in a new tab) splits the metric this way and lists remedies for each phase.

What counts and what the thresholds are

According to the web.dev LCP article (Opens in a new tab), the metric reports the render time of the largest image, text block or video visible in the viewport, measured from when the user first navigated to the page. A good value is 2.5 seconds or less, anything above 4.0 seconds is poor, and the range between needs improvement. The assessment uses the 75th percentile of page loads, segmented by mobile and desktop.

Candidates include img elements, image elements inside an SVG, video elements (using the poster image or the first frame, whichever comes first), elements with a url() background image, and block-level elements containing text. CSS gradients do not count. Chromium heuristics exclude elements with zero opacity, elements covering the full viewport that look like backgrounds, and placeholder or low-entropy images.

The four phases and their ideal shares

The guide stresses that each phase only makes sense relative to the others and that the two delay phases should be close to zero. It also warns against turning the percentages into fixed millisecond budgets. Use the table as a diagnostic: the phase furthest from its ideal is where to start.

Why a fix can just move the delay

The guide notes that optimizing one phase can shift time into another. Compressing an image helps little if the element then sits waiting for a render-blocking stylesheet. After each change, measure all four phases again rather than only the total.

Reading the table: three typical profiles

These are illustrative profiles, not measurements. A page whose load delay dominates has a discovery problem, so look at markup and priority. A page whose load duration dominates has a payload problem, so look at file size, format and caching. A page whose render delay dominates has a main-thread or blocking-resource problem, so look at CSS and scripts. A page that is slow in the first phase is waiting on the server, and no front-end image trick will repair that.

Finding the LCP Element

You cannot fix the right thing without knowing what the browser chose. People often assume the banner is the LCP element when it is actually a headline, or when mobile shows a different element from desktop.

Start with the field, then take one page

The guide recommends checking real-user data first, either CrUX through PageSpeed Insights or Chrome DevTools, or your own RUM tooling, because lab results can differ. It also tells you to confirm that the CrUX data is for the specific page and not the whole origin. So find the failing template from the field data, then investigate a single representative URL.

Matching the element to the waterfall

Once you know the LCP element, locate its resource on the network waterfall next to the initial HTML request. Two questions matter: how long after the HTML request does the image request begin, and how long does it take to finish? Lighthouse and DevTools show the phase breakdown, and for custom measurement you can use the LCP, Navigation Timing and Resource Timing APIs or the attribution build of the web-vitals library.

Why the candidate can change during load

The browser emits a new LCP entry each time a larger element is painted. A page might first show a block of text, then a hero image once it arrives, and the image becomes the candidate. A painted element stays the candidate even if it is later removed, unless a larger one appears, and reporting stops when the user interacts with the page. A page that looks text-driven may in fact be waiting on a late image.

Discoverability from the HTML

If the image is an img element in the initial HTML, the preload scanner can find it early. The guide says images referenced only from external CSS or JavaScript, and CSS background images, are invisible to that scanner and need a preload in the HTML, either a link rel="preload" or a Link header. Hosting critical resources on the same origin as the HTML also helps reuse the connection.

When the LCP element is text

Not every page has an image as its LCP element. If a heading or paragraph block is the largest item, image tuning will not change the result. Look instead at render delay, such as the font loading strategy and render-blocking CSS. The guide suggests considering font-display values other than auto or block so text is not held back by fonts.

Quick checklist for locating the element

• The failing template was identified from field data.
• The LCP element was checked on both mobile and desktop.
• You know whether it is an img, a background image or a text block.
• The image URL appears in the initial HTML.
• On the waterfall, its request starts soon after the HTML request.

When fetchpriority and Preload Help

People mix these up, yet they solve different problems. Preload makes a resource discoverable. fetchpriority changes how urgently an already known resource is fetched.

What fetchpriority does

The web.dev Fetch Priority article (Opens in a new tab) describes an attribute with the values high, low and auto, where auto is the default and lets the browser decide. It applies to resources loaded with link, img or script tags, and scripted requests use the priority property of the Fetch API. The page calls it a hint rather than a directive, so the browser may still apply its own priorities. Prioritization matters most when resources compete for bandwidth.

The browser support listed there is Chrome 102, Edge 102, Firefox 132 and Safari 17.2. In browsers that do not know the attribute it is ignored, which is harmless but brings no gain.

Giving high priority sparingly

The LCP guide advises putting fetchpriority="high" on the likely LCP image but only on one or two images. Marking everything high defeats the point. One case study on the Fetch Priority page reports Google Flights improving LCP from 2.6 s to 1.9 s by raising the priority of its LCP image. That is a reported case and not a promise for your page.

Lowering priority is equally useful

The guide suggests fetchpriority="low" for hidden content such as off-screen carousel slides. The Fetch Priority article gives the pattern of high on the first visible carousel image and low on the others, and notes that off-screen images can otherwise be boosted to high even when loading="lazy" is present. A separate example there preloads a non-critical script with fetchpriority="low", and fetch() calls can take priority: 'low' for background data. A low-priority script can still block the parser, so low is a scheduling hint, not a way to remove blocking.

When a preload is warranted

Preload is a mandatory fetch that improves discoverability, while fetchpriority changes priority but does not help discovery. If the image sits in the initial HTML as an img, the scanner finds it on its own and an extra preload is unnecessary. The responsive-image preload page repeats this: if the image is easy to find in the markup, let the preload scanner discover it.

When the image is a CSS background or comes from external CSS or JavaScript, a preload belongs in the HTML. The Fetch Priority article says that when a CSS background image is the LCP element, add fetchpriority="high" to the preload. Image preloads default to low priority, so without that attribute the benefit may be limited.

Moving a background image into an img element

A preload rescues a background image, but the durable fix is often to present the picture as real content with an img element. Then the scanner finds it unaided, srcset and sizes can pick a size per device, alt text can describe it, and width and height reserve its space. Keep background images for decoration. Cover, product and news images are page content and suit img better.

Preloading a responsive image correctly

A plain href preload fetches one fixed file regardless of the viewport, so the wrong size may download. The web.dev page on preloading responsive images (Opens in a new tab) shows the fix: add imagesrcset and imagesizes to the link element, using the same syntax as srcset and sizes on the img. Both run the same selection logic.

• There is no preload equivalent for the picture element. Its sources are checked in order, while preloads have no order, so convert breakpoints into non-overlapping media ranges, each with its own preload.
• For type, preload only the most preferred format, because several type-specific preloads all download.
• Responsive preloads may not work in HTTP Link headers and cannot be used with 103 Early Hints, so use link elements.
• A late meta viewport tag can make the wrong image start loading, because Chrome processes these attributes after the first HTML chunk.

Decision table

Why Lazy-Loading Hero Images Backfires

Lazy loading is a good tool for images below the fold. Applied to the first screen it works against you.

What lazy loading does to the first screen

loading="lazy" defers an image until it reaches a calculated distance from the viewport. For a hero image this means the browser must finish layout and decide that the image is near the viewport before it starts the fetch, which adds delay that nothing recovers. The LCP guide is blunt: never lazy-load the LCP image, and in its pitfalls it says doing so reliably hurts LCP. The web.dev article on browser-level image lazy-loading (Opens in a new tab) agrees: do not lazy-load images likely to be in the viewport at load, especially the LCP image, and use loading=lazy only for images outside the initial viewport.

Eager loading is the browser default and is the same as omitting the attribute. To repair a hero image you do not need to add eager; simply remove lazy.

Where the mistake usually comes from

The attribute rarely arrives by deliberate choice. A theme or plugin adds loading="lazy" to every image, a component library applies it to all img tags, an editor drops a banner into the body of an article, or a script-based lazy loader swaps src for data-src. In that last case the image URL is not even in the initial HTML, so discovery depends entirely on JavaScript. For the wider picture of lazy loading and crawlers, see lazy loading and SEO for images, iframes and scroll-loaded content.

Example scenario: a store template

This is an example scenario without figures. A store template lazy-loads every product photo, including the large photo at the top of each product page. Field data shows the product group failing LCP and the phase breakdown shows a large load-delay share. The fix is template-level: remove lazy from the first image, add fetchpriority="high" to it, and leave lazy on thumbnails and gallery images further down. Because the change sits in a shared template, verify several products rather than one.

Doing it right below the fold

Below the fold, lazy loading is correct. The browser fetches distant images only when the user scrolls near them. The article reports that Chrome lowered the 4G threshold from 3000px to 1250px and the slower-connection threshold from 4000px to 2500px, and that these values are hardcoded. Always give lazy images width and height. The article recommends dimensions on every img regardless of lazy loading, and notes that without them dimensions default to 0x0 pixels, which can cause layout shifts. For the file side of image SEO, see image SEO: optimize images for Google.

Audit checklist

• No loading="lazy" on any image that appears on the first screen.
• The LCP image is an img in the HTML, not a script-built element.
• Below-the-fold images have loading="lazy", width and height.
• Only the first visible carousel slide is high priority.
• No image depends on data-src and a script alone to be found.

Verifying the Change

A change is not an improvement until measured. Field data makes the decision and lab data explains why.

Before and after

Before editing, record the LCP element, the four-phase breakdown and the start time of the image request on the waterfall. Repeat under the same conditions afterwards. If the fix worked, the load-delay share shrinks and the image request starts right after the HTML. If the total barely moved while the delay fell, time has migrated to another phase. TTFB is one of the four parts, and the guide lists redirects, cache-busting query parameters and slow server response as things that delay every later phase. For that side, see TTFB, caching and CDN server response time. For the overall framework, the page speed and Core Web Vitals guide applies.

If the image arrives early but paints late

Then look at element render delay. The guide's suggestions are to reduce render-blocking CSS or inline it if it is small, avoid synchronous scripts in the head, use server-side rendering or prerendering so content does not wait on client-side JavaScript, and break up long tasks. It adds that client-side rendering often leaves large gaps between FCP and LCP.

If the download itself is long

Shrink the file with correct sizing, modern formats and compression. Use a CDN or image CDN where it helps, remembering the connection cost of third-party domains, and reduce other high-priority requests that compete for bandwidth.

Symptom to cause

Reporting and limits

Note the template, the image, the change and its date in the report. Field data updates with a lag, so do not expect an instant result. Lighthouse and CrUX can disagree, and the guide says to prefer field data when they do. A fix in one template does not spread by itself: product, category and article pages each have their own LCP element, so confirm each one separately. No step here guarantees a ranking outcome.

Frequently Asked Questions

How do I find my LCP image?

Find the failing page group in field data, then open Lighthouse or Chrome DevTools and read the LCP element and the phase breakdown. Match its resource to the initial HTML request on the network waterfall. The LCP element can differ between mobile and desktop, so check both.

Should I add fetchpriority="high" to every image?

No. web.dev recommends it only for the likely LCP image and for no more than one or two images. It is a hint, so the browser can still apply its own priorities. Use fetchpriority="low" for off-screen content such as hidden carousel slides.

What is the difference between preload and fetchpriority?

Preload is a mandatory fetch that makes a resource discoverable early. fetchpriority changes the priority of a resource the browser already knows about. If the image is an img in the initial HTML, fetchpriority is usually enough. A CSS background or script-inserted image needs a preload.

How do I preload a responsive image?

Use a link rel="preload" as="image" element with imagesrcset and imagesizes that mirror the srcset and sizes on the img, plus fetchpriority="high". A plain href downloads one fixed file and can pick the wrong size. For picture elements, convert breakpoints into non-overlapping media ranges.

Why is lazy-loading the first-screen image harmful?

The browser waits until the image is near the viewport before fetching it, which delays the LCP. web.dev tells you not to lazy-load images likely to be in the viewport at load, especially the LCP image. Eager is the default, so removing lazy is enough.

How can I confirm the change worked?

Record the LCP element, the four-phase breakdown and the image request start before and after. Lab data explains the cause, but field data decides, and it updates with a delay, so keep a dated change log.

Conclusion

A slow LCP image is usually a discovery, priority or lazy-loading problem rather than a file-size one. Identify the LCP element, read the four phases, make the image visible in the initial HTML, give high priority to one or two likely LCP images, use a correct preload when the image is not in the markup, and never lazy-load the first screen. Then confirm the result with before-and-after measurements. No step guarantees a ranking outcome; the measurable benefit is that visitors see the main content earlier.

If you need consistent technical guides, product page copy or articles with cover images, you can look at the Akua Adforce content writing service; scope and terms are listed on the product page.