Critical Image Extraction for LCP and SEO

Last updated: June 28, 2026

Critical image extraction means finding the one image that controls the first visual impression of a page. On many product pages, landing pages, and blog posts, that image is the hero, the main product photo, or a large above-the-fold illustration. If you identify it early, you can preload or prioritize the right file instead of speeding up every image equally.

Quick answer: how do you extract the critical image?

Use critical image extraction to name the image most likely to become the Largest Contentful Paint element, then give that file special loading treatment. Usually that means the largest visible image in the initial viewport gets fetchpriority="high", no lazy loading, stable dimensions, and sometimes a <link rel="preload">.

Do not preload every large file. Preload the hero or product image only when the browser would otherwise discover it late, such as inside CSS, a carousel, a client-rendered component, or a responsive <picture> stack with complex source selection.

After the change, verify the result. Google's Largest Contentful Paint documentation defines LCP around the largest visible content element, and PageSpeed Insights will show which element was measured. Chrome DevTools should also show the critical image request early in the waterfall.

Use this order:

1. Load the page at a realistic mobile viewport.
2. Find the largest above-the-fold image or poster.
3. Check whether PageSpeed or Lighthouse reports it as LCP.
4. Remove loading="lazy" from that image.
5. Add dimensions or an aspect ratio.
6. Add fetchpriority="high" when it is an <img>.
7. Preload it only when discovery is late.
8. Keep below-fold images lazy.
9. Re-test after layout, CMS, or hero copy changes.

What counts as a critical image?

A critical image is the image a visitor waits for before the page feels useful. It is often, but not always, the LCP element. A small logo at the top of the page may load first, but it rarely controls perceived readiness. A hero image that occupies half the phone screen usually does.

Use rendered size, viewport position, and purpose together. A thumbnail in a navigation menu is visible, but it is not the main content. A background image behind the headline may be critical if it is the largest visible element. A social card image in metadata is important for sharing, but it is not fetched for the rendered page unless the template also displays it.

Image candidate	Critical for LCP?	Loading treatment	Common mistake
Above-the-fold hero image	Usually yes	Eager, high priority, maybe preload	Lazy-loaded by a global image component
Main product photo	Usually yes	Eager, high priority, stable size	Hidden behind carousel JavaScript
Logo or small icon	Usually no	Normal priority	Preloaded even though it is tiny
Social sharing image	No for page LCP	Metadata only	Confused with rendered hero
Below-fold diagram or gallery	No	Lazy-load	Competes with the hero if loaded eagerly

Google's LCP guidance lists <img> elements, image elements inside SVG, video poster images, and CSS background images as possible candidates. That means extraction cannot stop at searching for the first <img> tag. You need to inspect the rendered page.

For adjacent work, keep the broader image optimization for SEO checklist nearby. Critical image extraction decides priority; compression, filenames, alt text, and structured content still decide whether the image is useful after it loads.

Which image should get preload or high priority?

Give high priority to one image: the current page's likely LCP image. If two candidates are close, choose the one that is largest on mobile first, because mobile Core Web Vitals are usually harder to pass.

Use fetchpriority="high" when the critical image is a normal <img> or the fallback <img> in a <picture> element. Google's fetch priority guidance explains that this hint changes the browser's resource priority without changing the markup discovery path.

Use preload when discovery is the problem. MDN's rel="preload" reference describes preload as a way to request resources earlier in page load. That helps when the image URL appears in CSS, arrives after hydration, or sits behind markup the browser cannot discover soon enough.

Situation	Better choice	Why
<img> hero appears in server-rendered HTML	fetchpriority="high"	Browser can discover it already
CSS background hero is the visual LCP	Preload exact URL	Browser may discover it after CSS
Responsive <picture> hero is visible immediately	fetchpriority="high" on <img>	Keeps source selection in markup
Client-rendered carousel starts with hero image	Server-render first slide or preload	JavaScript can delay discovery
Two large heroes alternate by media query	Preload only matching candidate	Avoids wasting bandwidth

For a normal responsive image, the markup can look like this:

<img
  src="/images/product-hero-960.webp"
  srcset="/images/product-hero-480.webp 480w, /images/product-hero-960.webp 960w, /images/product-hero-1440.webp 1440w"
  sizes="(max-width: 640px) 100vw, 960px"
  width="960"
  height="640"
  fetchpriority="high"
  alt="Black leather backpack shown open with laptop sleeve visible"
>

If the image is a CSS background and you cannot move it to HTML yet, preload the same asset the initial viewport will use:

<link
  rel="preload"
  as="image"
  href="/images/home-hero-960.webp"
  imagesrcset="/images/home-hero-480.webp 480w, /images/home-hero-960.webp 960w"
  imagesizes="100vw"
>

The image preloading guide covers the syntax in more detail. The important rule here is narrower: preload after extraction, not before it.

How do you avoid lazy-loading the wrong image?

Lazy loading belongs below the first viewport. It is a mistake on the extracted critical image because it tells the browser to wait until layout and distance checks happen. Google's browser-level lazy loading guide warns against lazy-loading images that are immediately visible.

Audit global image components carefully. Many frameworks make lazy loading the default because most images are below the fold. That default breaks pages where the hero image is wrapped in the same component as gallery thumbnails.

Check these places:

1. CMS rich-text image renderers.
2. Product gallery components.
3. Blog cover image components.
4. Homepage hero background utilities.
5. Sliders that hide all slides until JavaScript runs.
6. Placeholder components that swap data-src into src.
7. Third-party personalization blocks.
8. A/B testing wrappers that delay hero markup.

The fix is usually small. Add a priority, aboveFold, or isLcp option to the component and make the template owner choose it explicitly. Below-fold body images should still use native lazy loading, especially long guides with screenshots and diagrams.

For mobile-heavy pages, pair this with the mobile image optimization guide. A correctly prioritized hero still performs poorly if the phone downloads a 2400 px desktop crop for a 390 px slot.

How should you extract images from a real page?

Start in the browser, not in the asset library. The asset library tells you what exists; the browser tells you what users receive.

Use this manual workflow:

1. Open the page at 390 px wide and reload with cache disabled.
2. Note the largest visible image before scrolling.
3. Inspect that element and record its final URL.
4. Check whether it is an <img>, <picture>, video poster, or CSS background.
5. Confirm the rendered width and height.
6. Compare the downloaded file width with the rendered slot.
7. Look for loading="lazy" or JavaScript-delayed src assignment.
8. Check DevTools Network for request start time and priority.
9. Run PageSpeed Insights and record the LCP element.
10. Repeat on desktop if the hero changes by breakpoint.

For template audits, make a small extraction table before editing code:

Page type	Likely critical image	Where URL comes from	Extraction note
Blog post	Cover image after intro	Frontmatter image field	Keep cover and rendered body image in sync
Product detail	Primary product photo	Product media array	First visible gallery slide must not wait for JS
Landing page	Hero background or illustration	CSS, CMS, or page component	Prefer HTML image if it conveys content
Category page	First large promo tile	Collection data	Do not prioritize every grid item
Case study	Above-fold customer screenshot	CMS image block	Crop for mobile text readability

I generated the diagrams in this article as WebP files and kept each under 40 KB. That is not a universal target for photos, but it is a useful reminder: the extracted image should be right-sized before it receives priority. If the file is still huge, use the image compression deep dive and batch resize guide before shipping.

How do you verify the critical image in tools?

Verification has two jobs. First, prove the selected image is actually the LCP element or a serious LCP candidate. Second, prove the browser discovers it early enough.

Use PageSpeed Insights for field and lab context. The diagnostics panel usually names the LCP element, and the screenshot helps confirm whether the reported element matches the page's visual hero. Use Lighthouse or DevTools Performance when you need a local trace.

Use DevTools Network for request behavior:

1. Filter by image requests.
2. Reload with cache disabled.
3. Confirm the critical image starts near the top of the waterfall.
4. Check that priority is High or upgraded early.
5. Confirm below-fold images are not all competing at the same time.
6. Check status code, content type, transfer size, and cache headers.

Use rendered HTML inspection for markup mistakes:

1. The critical image has src or discoverable srcset in initial markup.
2. It does not have loading="lazy".
3. It has width and height, or a stable CSS aspect ratio.
4. Its alt text describes the visible subject when the image is content.
5. The CDN URL returns a crawlable 200 response.

For search, Google's image SEO best practices also emphasize descriptive filenames, alt text, and useful surrounding text. Critical image extraction improves loading priority, but the same image still needs search context.

What breaks critical image extraction?

The most common failure is treating every page like it has the same hero. A blog index, product page, and pricing page can have different LCP candidates. The extraction step must happen at the template level and at the breakpoint level.

Watch for these traps:

1. Preloading the Open Graph image. The social card image may never render on the page.
2. Lazy-loading the first product photo. Product galleries often inherit thumbnail defaults.
3. Prioritizing every carousel slide. Only the first visible slide can be critical at load.
4. Ignoring mobile crops. Desktop and mobile can select different LCP images.
5. Using CSS backgrounds for meaningful content. They are harder to prioritize and less accessible.
6. Forgetting dimensions. Priority does not prevent layout shift.
7. Shipping one oversized source. A high-priority 3 MB image is still slow.
8. Testing only on local Wi-Fi. Slow 4G exposes discovery delays.

If the problem is mostly file weight, start with the complete image optimization checklist. If the problem is format choice, compare AVIF vs WebP before changing delivery rules.

Summary: critical image extraction checklist

Critical image extraction is a page-speed decision, not an asset naming exercise. Find the image that controls the first viewport, give only that image early loading treatment, and keep the rest of the page from competing with it.

Before publishing, confirm:

1. The likely LCP image is named in the template or audit notes.
2. Mobile and desktop candidates are checked separately.
3. The critical image is not lazy-loaded.
4. fetchpriority="high" is used for a visible <img> LCP candidate.
5. Preload is used only when discovery is late.
6. The selected file is resized and compressed.
7. Width and height, or an aspect ratio, reserve layout space.
8. Below-fold images remain lazy.
9. PageSpeed Insights reports the expected LCP element.
10. DevTools shows the critical image request early in the waterfall.
11. The CDN URL returns 200 with the expected image type.
12. The image has useful alt text and nearby explanatory content.

Frequently asked questions

What is critical image extraction?

Critical image extraction is the process of identifying the single image most likely to become the page's Largest Contentful Paint element so it can receive priority loading treatment.

Which image should get fetchpriority="high"?

Give fetchpriority="high" to only one image, the current page's likely LCP candidate, such as a server-rendered hero <img> or the fallback <img> inside a <picture> element.

When should I preload the hero image instead of just using fetchpriority?

Preload the hero image only when the browser would otherwise discover it late, such as inside CSS, a client-rendered component, or a complex <picture> source set.

Why is lazy-loading the critical image a mistake?

Lazy-loading tells the browser to wait on layout and distance checks before fetching, which delays the exact image that decides how fast the page feels to load.

How do I verify the critical image is actually the LCP element?

Run PageSpeed Insights or Lighthouse to see which element is reported as LCP, then check DevTools Network to confirm that same image request starts early with high priority.

Does the Open Graph image count as the critical image?

No, the Open Graph image is metadata for link previews and usually never renders on the page itself, so preloading it wastes bandwidth without improving LCP.

Should mobile and desktop pages use the same critical image?

Not always; mobile and desktop breakpoints can select different hero images, so check each viewport separately since mobile Core Web Vitals are usually the harder target to pass.

What is the most common critical image extraction mistake?

The most common mistake is treating every page template the same way, when a blog index, product page, and pricing page often each have a different LCP candidate.

Image credits

• Cover, LCP candidate diagram, priority decision tree, and verification trace were generated for this article with ImageMagick and exported as WebP.