Lesson 6 of 14

Native Lazy Loading, Responsive Images, and Image Sitemaps

Q: A product page's Lighthouse score shows a poor LCP, and you notice every image on the page — including the large hero banner — has loading="lazy" applied uniformly via a shared component. How do you diagnose and fix this, and how would you prevent the same mistake elsewhere on the site?

A strong answer covers: Identifies that loading="lazy" on the LCP candidate itself is the direct cause of the regression, not a coincidence; Explains loading="lazy" defers fetch until near-viewport, which is the wrong signal for an above-the-fold hero image; Proposes a concrete fix: eager load (or explicit loading="eager"/no attribute) plus fetchpriority="high" for the hero specifically, lazy for everything else; Distinguishes this from decoding="async" and from srcset/picture, showing these are independent, separately-tunable attributes; Mentions a systemic fix — e.g. a prop/flag on the shared image component so the LCP candidate is opted out explicitly, rather than a one-off patch.

loading="lazy" and <picture> replaced a decade of IntersectionObserver libraries with two HTML attributes — but applying loading="lazy" to the wrong image is one of the most common real Core Web Vitals regressions, and image discovery for search is a separate mechanism entirely.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Native Lazy Loading, Responsive Images, and Image Sitemaps

What interviewers actually ask about this, and what a strong answer has to cover.

A product page's Lighthouse score shows a poor LCP, and you notice every image on the page — including the large hero banner — has loading="lazy" applied uniformly via a shared component. How do you diagnose and fix this, and how would you prevent the same mistake elsewhere on the site?

A strong answer covers

Identifies that loading="lazy" on the LCP candidate itself is the direct cause of the regression, not a coincidence
Explains loading="lazy" defers fetch until near-viewport, which is the wrong signal for an above-the-fold hero image
Proposes a concrete fix: eager load (or explicit loading="eager"/no attribute) plus fetchpriority="high" for the hero specifically, lazy for everything else
Distinguishes this from decoding="async" and from srcset/picture, showing these are independent, separately-tunable attributes
Mentions a systemic fix — e.g. a prop/flag on the shared image component so the LCP candidate is opted out explicitly, rather than a one-off patch

Likely follow-ups

How would you identify which image on a given page is actually the LCP candidate, programmatically or via tooling, rather than guessing?
If the site also has a large JS-rendered image gallery that isn't showing up in Google Image search, what would you check first?

The plain-language idea

Before 2019, deferring offscreen images until they scrolled into view meant a JavaScript library watching scroll position (or, if you were fancier, an IntersectionObserver) and swapping a placeholder src for the real one. Native lazy loading collapses that into a single HTML attribute:

loading="lazy" on <img> or <iframe> tells the browser to defer fetching that resource until it's near the viewport — no JS, no library, no placeholder swap.
decoding="async" tells the browser it's allowed to decode the image off the main thread, so a large image finishing its fetch doesn't block rendering of text and other content that's already ready. It's independent of loading — you can use either without the other, but they're commonly paired.
<picture> with srcset/sizes solves a different problem: not when to load an image, but which image to load. srcset on a <source> or <img> lists candidate files at different resolutions; sizes tells the browser how much layout space the image will occupy at different viewport widths, so it can pick the smallest candidate that's still sharp enough — without JS, without you hardcoding breakpoints in a component. <picture> additionally allows art direction: serving a genuinely different crop or image entirely at different breakpoints (a tight portrait crop on mobile, a wide landscape on desktop), not just a smaller version of the same file.

The mistake that makes this section belong in an SEO/performance track and not just a "modern HTML" one: loading="lazy" on the actual LCP image directly damages your Largest Contentful Paint score. The browser's LCP candidate is, by definition, the largest visible content element in the initial viewport — and lazy-loading is a signal to the browser that a resource is not urgent, deferring its fetch until layout confirms it's near-viewport. Applying "not urgent" to the one image Core Web Vitals is timing is a direct, self-inflicted regression, and it's a common one because "lazy-load your images" is repeated as blanket advice without the LCP carve-out.

See it in a real thing: correct lazy-loading on a product listing page

<!-- Hero/LCP image: eager, no lazy-loading, high fetch priority -->
<img
  src="/hero-product.avif"
  alt="Featured product"
  fetchpriority="high"
  width="800"
  height="600"
/>

<!-- Below-the-fold product grid: lazy-loaded, async-decoded -->
<picture>
  <source
    media="(max-width: 600px)"
    srcset="/product-2-mobile.avif 480w, /product-2-mobile-2x.avif 960w"
    sizes="100vw"
  />
  <source
    srcset="/product-2.avif 400w, /product-2-2x.avif 800w"
    sizes="25vw"
  />
  <img
    src="/product-2.avif"
    alt="Wireless keyboard, side profile"
    loading="lazy"
    decoding="async"
    width="400"
    height="300"
  />
</picture>

Only the below-the-fold grid images get loading="lazy". The hero image — the LCP candidate on this page — is loaded eagerly (the default; loading="eager" doesn't need to be written) and gets fetchpriority="high" instead, the opposite treatment.

Image sitemaps: a separate mechanism from lazy-loading entirely

Lazy-loading and responsive images control page performance — they say nothing about whether Google can find your images at all. That's what an image sitemap is for: an <image:image> extension inside your regular XML sitemap (or a dedicated image sitemap) that explicitly lists image URLs per page. It matters most when images are surfaced in ways a crawler might not reliably discover on its own — loaded via JavaScript after initial render, referenced only as CSS background-image, or served from a CDN domain different from the page's own. For a typical <img src> with real alt text, Google generally finds it fine during normal crawling; image sitemaps are a discovery aid for the harder cases, not a ranking signal, and not a replacement for descriptive alt text and filenames.

What people usually miss

Watch out

Never lazy-load the LCP image — it's the single most common real-world Core Web Vitals regression tied to this feature, precisely because "lazy-load your images" gets repeated as unconditional advice.
loading="lazy" and decoding="async" solve different problems and are independent attributes — one defers the fetch, the other moves decode work off the main thread. Using one doesn't imply the other.
srcset/sizes picks a resolution; <picture> with multiple <source> elements enables art direction — a genuinely different image per breakpoint, not just a smaller file. Conflating the two leads to reaching for <picture> when plain srcset on an <img> would do.
Lazy-loaded <iframe>s are the same LCP/INP trap as images, but less obviously — an embedded video near the top of the viewport, lazy-loaded reflexively, delays exactly what CWV is measuring.
Image sitemaps are a discovery mechanism, not a ranking or performance one — they don't make images load faster or rank better; they only help a crawler find images it might otherwise miss, particularly JS-rendered or CDN-hosted ones.

Why this matters in interviews

A candidate who says "always lazy-load images for performance" without the LCP carve-out is giving advice that's actively wrong for the one image that determines the page's headline Core Web Vitals score — interviewers probing real production experience listen specifically for that exception. Being able to also separate "how fast do images load" (lazy-loading, srcset) from "can Google find my images at all" (image sitemaps) signals the candidate isn't treating SEO and performance as the same lever, which is a common shallow-answer tell.