Responsive Images (srcset)

TL;DR — Responsive images let a browser load a right-sized version of a picture instead of one giant file — a small one on a phone, a big one on a desktop. You do it with the srcset and sizes attributes on your <img> tag (list the sizes you have; the browser picks). This doesn’t directly boost your rankings, but it makes pages faster and stops them from “jumping” as images load, and speed is something Google measures.

What responsive images are

A “responsive” image adapts to the device looking at it. Instead of sending the same huge photo to a phone and a desktop, you give the browser a few versions at different sizes and let it grab the one that fits. Phones get a small file; big screens get a big one. Less wasted data, faster pages.

There are two ways to do this, and it’s worth knowing which is which:

• srcset + sizes on <img> — the common one. Same picture, different sizes. You list what you have and the browser chooses. This is called resolution switching.
• The <picture> element — for when you want a genuinely different image at different sizes (say, a wide crop on desktop and a tall, tight crop on mobile), or a modern file format with a fallback. This is called art direction, and most sites don’t need it.

The basic version

Here’s what resolution switching looks like:

<img
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
  sizes="(max-width: 600px) 480px, 1000px"
  width="1000" height="1000"
  alt="Puppy with balloons" />

• src is your normal, always-there fallback. Keep it.
• srcset lists the versions you have and how wide each one is (1000w = 1000 pixels wide).
• sizes tells the browser how big the image will actually appear so it can pick the right file before it loads anything.
• width and height reserve space so the page doesn’t jump around while the image loads.
• alt is the same description you’d always write. Keep it identical across every version.

Why bother (the honest answer)

Responsive images don’t earn you a ranking “boost.” What they do is make pages load faster and stop the layout from shifting — and those are things Google measures as part of page experienceGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.. If a speed tool (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal., PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.) is nagging you to “properly size images,” srcset/sizes is the fix it’s asking for.

One more thing: this doesn’t change what shows up in Google Images. Google indexes the image in your src attribute — the responsive variants are just delivery. So keep your alt text, filename, and the main image URL the same no matter which version the browser loads.

Want the precise version — w vs x descriptors, when you actually need <picture>, the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. and layout-shift mechanics, and the mobile-indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. rules — switch to the Advanced tab.

TL;DR — Two jobs, one syntax family. srcset/sizes on <img> = resolution switching (same image, browser picks best-fit — a suggestion); <picture> = art direction or format switching (author-dictated crops/formats — a command). Most sites only need the first. Responsive images are not a direct ranking signal and don’t change what Google indexes — Google indexes the src URL, so keep alt text, filenames, and image URLs stable across breakpoints (mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost.). The real payoff is Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.: right-sizing images is the fix behind LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.’s “Properly size images” audit (fails at a 4KiB gap), and width/height (or aspect-ratio) — not srcset — is what prevents CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.. Don’t lazy-load the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. image. I reuse the exact srcset + width/height pattern from my Ahrefs CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. piece.

Two different jobs, one syntax family

Everything in this topic collapses into two mechanisms, and half the confusion out there comes from mixing them up:

1. Resolution switching — the same image at different sizes or pixel densities. You give the browser a menu with srcset and sizes on the <img>, and the browser decides which file to fetch based on the viewport and screen density. This is the common case.
2. Art direction — a genuinely different image per condition: a wide crop on desktop, a tight vertical crop on mobile, or a different file format entirely. Here you dictate the choice with the <picture> element.

The web.dev Learn: Responsive images course frames the difference exactly right: with srcset the browser gets suggestions, whereas “the picture element gives commands.” And the scope-setting line worth tattooing on the wall, also from web.dev: “You probably won’t need to use the picture element for most of your responsive images — the srcset and sizes attributes on the img element cover a lot of use cases.” Reach for <picture> only when you actually need a different image, not a different size of the same one.

srcset and sizes — resolution switching

w-descriptors vs. x-descriptors

srcset takes a comma-separated list of candidate files, each tagged with a descriptor. There are two kinds:

• Width descriptors (w) — you state each file’s intrinsic pixel width (puppy-2000.jpg 2000w). The browser combines that with your sizes value to work out which file best fits the space and the device’s pixel density. This is the flexible option and what you’ll use most of the time.
• Pixel-density descriptors (x) — you state which file is for which device pixel ratio (logo.png 1x, logo@2x.png 2x). Use these for fixed-size images (an avatar, a logo) where the displayed size never changes; you don’t need sizes with x descriptors.

Rule of thumb: fluid, content-width images → w descriptors + sizes; fixed-size UI images → x descriptors.

Why sizes matters (and what happens if you skip it)

With w descriptors, sizes isn’t optional cosmetics — it’s how the browser knows how big the image will render so it can choose before layout. Per web.dev, sizes “tells the browser what size you expect the image to be displayed at under different conditions,” as a comma-separated list of media conditions and widths:

sizes="(max-width: 600px) 480px, 1000px"

Read it as: “if the viewport is 600px or narrower, the image will be about 480px wide; otherwise, about 1000px.” Omit sizes and the browser assumes the image fills the full viewport width (100vw) — so on a wide screen it may pull your largest file for an image that’s actually renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. at 400px, quietly defeating the whole point. Missing sizes is the single most common srcset mistake.

Don’t guess at those width values from the layout in your head — check the image’s actual rendered CSS width in the browser (DevTools → Elements → the computed width of the <img> box) at each breakpoint you care about, and set sizes to match. A sizes value that doesn’t match the real rendered width still causes the browser to select the wrong candidate even though the markup is syntactically correct — syntax validation alone won’t catch that; see the currentSrc check below to confirm what actually loaded.

Worked example (my reusable pattern)

This is the exact pattern from my Ahrefs piece, What Is Cumulative Layout Shift (CLS) & How To Improve It, expanded with sizes:

<img
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w,
          puppy-2000.jpg 2000w,
          puppy-3000.jpg 3000w"
  sizes="(max-width: 600px) 480px, 1000px"
  width="1000" height="1000"
  alt="Puppy with balloons" />

Every piece is load-bearing: src is the fallback and the URL Google indexes; srcset lists the candidates with w descriptors; sizes tells the browser the rendered width; width/height reserve space (the CLS fix — more below); alt stays identical no matter which file loads.

The picture element — art direction and format switching

When you actually need it

Use <picture> for two things srcset can’t do:

1. Art direction — a different crop per breakpoint. web.dev’s example: on a narrow phone you might serve a tall, tight crop; on a wide desktop, a short, wide one. Same subject, deliberately different framing.
2. Format switching — offer AVIF/WebP with a JPEG fallback via <source type="…">, letting the browser take the first format it supports. This ties straight back to the format guidance on the Image SEOImage SEO is optimizing the images on your pages so search engines can discover, crawl, index, and rank them — in Google Images and visual search, and as part of standard web results. It spans file format, filenames, alt text, compression, responsive markup, structured data, and image sitemaps. hub.

The syntax (and the fallback rule)

The <picture> element wraps one or more <source> elements and always ends with a plain <img>:

<!-- Art direction: different crop per breakpoint -->
<picture>
  <source media="(max-width: 600px)" srcset="hero-crop-mobile.jpg">
  <img src="hero-crop-desktop.jpg" width="1200" height="675"
       alt="Product hero shot">
</picture>

<!-- Format switching: modern format with a fallback -->
<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" width="1200" height="675" alt="Product hero shot">
</picture>

That trailing <img src> is not optional. Google states it directly: per section 4.8.1 of the HTML Standard, “make sure that you provide an img element as a fallback with a src attribute when using the picture element.” It’s the file older browsers and crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. fall back to — and, again, the one Google indexes.

Does srcset help SEO? Direct vs. indirect

Here’s the framing every competing guide fumbles, so I’ll be blunt.

Directly: no. Responsive-image markup is not a ranking signal the way alt textAlt text is the value of the `alt` attribute on an HTML `<img>` element — a short text substitute chosen for the image's purpose and context, not a literal description of what it shows. It makes images accessible to screen-reader users and helps search engines understand images, mainly for image search. or filenames are for image search. Adding srcset doesn’t lift your positions, and it doesn’t change what appears in Google Images. Google indexes the image referenced in src; the srcset/<picture> variants are a delivery mechanism, not separately indexable assets. Keep your alt text, filename, and structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. attached to that primary src image.

Indirectly: yes, and it’s one of the biggest levers you have. Right-sized images are the most effective concrete fix for two Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. — LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. and CLS — which feed Google’s page-experience signals. That’s the whole payoff. It’s the same shape as the WebP/AVIF story on the Image SEOImage SEO is optimizing the images on your pages so search engines can discover, crawl, index, and rank them — in Google Images and visual search, and as part of standard web results. It spans file format, filenames, alt text, compression, responsive markup, structured data, and image sitemaps. hub: no boost for the format itself, the win is speed.

Responsive images and LCP

Oversized images are one of the most common causes of a slow Largest Contentful Paint, and responsive images are LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.’s recommended fix. The Lighthouse “Properly size images” audit lists “all images in your page that aren’t appropriately sized, along with the potential savings” — anything bigger than it needs to be “just results in wasted bytes and slows down page load time.” Its fix, verbatim: “With responsive images, you generate multiple versions of each image, and then specify which version to use in your HTML or CSS using media queries, viewport dimensions, and so on.”

Two specifics worth knowing:

• The failure threshold is 4KiB. Lighthouse only flags an image when “the rendered size is at least 4KiB smaller than the actual size.” Small overshoots don’t count; serving a 3000px file into a 400px slot does.
• A tooling shortcut. Google recommends RespImageLint, “a helpful bookmarklet for identifying the optimal srcset and sizes values for your images.” Run it before you hand-calculate breakpoints.

Don’t lazy-load the LCP image

This is the rule people break most. srcset on your hero is fine — but never pair it with lazy loadingLazy loading defers loading of off-screen or non-critical resources — usually images and iframes — until they're about to enter the viewport. The native way to do it is the loading=\"lazy\" HTML attribute, which needs no JavaScript. on the LCP element. The largest above-the-fold image should load eagerly with fetchpriority="high", exactly as the Image SEO hub covers. And when you build a responsive <picture> hero, keep the swap logic native: Google warns that it “won’t load content that requires user interactions” like swiping or clicking, so a JS scheme that only loads the real image after interaction hides it from Google.

Responsive images and CLS

Here’s the trap: srcset alone does nothing for layout shift. Resolution switching decides which file loads; it doesn’t reserve space for it. Left without dimensions, per web.dev’s Optimize CLS guide, “as images load, text shifts down the page to make room for them” — because the space “can’t be allocated for it until the browser starts to download it and can determine its dimensions.”

The fix is explicit dimensions, and it composes with responsive markup:

• Set width and height attributes on the <img>. Modern browsers “set the default aspect ratio of images based on an image’s width and height attributes,” so those two numbers reserve the right box before any srcset variant downloads. (web.dev)
• Pair them with height: auto in CSS for fluid containers. This is the part that looks contradictory but isn’t: web.dev’s own guidance is to “use CSS to resize the image to the width of the container” and “set height: auto; to avoid using a fixed value for the image height.” The HTML attributes set the intrinsic aspect ratio; the CSS lets the image scale fluidly. Together they prevent CLS and stay responsive.
• Or use CSS aspect-ratio to reserve the space when you can’t set attributes.

Which kills a persistent myth: width/height attributes don’t break fluid layouts. Attributes + height: auto is the correct combo, not a conflict. I walk through the full layout-shift mechanics in my Ahrefs CLS article; the short version is “reserve the space so that there’s no shift” and let the image fill it.

Mobile-first indexing implications

Google indexes primarily the mobile version of your pages, so two rules matter more than they used to when you’re serving responsive variants:

• Keep alt text identical across breakpoints. Google’s mobile-first indexing best practices say to “make sure that the mobile site has the same alt text for images as the desktop site.” An art-directed mobile crop must not drop context Google needs.
• Keep image URLs stable. Don’t use URLs that change every time the page loads for images. This dovetails with Google’s Image SEO guidance to consistently reference the image with the same URL so it can cache and reuse it. Responsive CDNs that mint a fresh URL per request break this — pin stable URLs for your variants.

Google’s own summary of why to bother is plain: “designing responsive web pages leads to better user experience, since people can access them across a plethora of device types.”

What about Bing?

There’s no Bing-specific guidance on srcset, sizes, or the <picture> element — Bing’s public documentation doesn’t address responsive-image markup at all. So don’t justify responsive images with a Bing algorithm hook; the case is performance and UX, which Bing (like Google) treats as page-experience quality rather than something you can point at a documented responsive-images rule for.

Common mistakes

• Forgetting sizes with w descriptors — the browser assumes 100vw and may fetch your biggest file for a small slot.
• Dropping the fallback src on <picture> — a spec violation Google explicitly flags, and it’s the URL crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. index.
• Mismatched width/height ratio vs. the actually-served image — still causes shift.
• Lazy-loading the LCP hero — delays LCP for no reason; load it eagerly with fetchpriority="high".
• Regenerating image URLs per request — breaks Google’s caching and the mobile-first “stable URL” rule.
• Reaching for <picture> when srcset/sizes would do — unnecessary complexity; web.dev says most sites don’t need it.

Where this sits

This is the sizing-and-delivery deep dive under the broader Image SEO hub — the performance half of image SEO, parallel to how the alt text guide handles the image-search half. For the layout-shift mechanics in full, see my Ahrefs CLS article; for LCP, fetchpriority, and the loading strategy, that’s Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. work wearing an image hat.

AI summary

A condensed take on the Advanced version:

• Two mechanisms, one family. srcset/sizes on <img> = resolution switching (same image, browser picks best-fit — a suggestion). <picture> = art direction or format switching (author-dictated crops/formats — a command). Most sites only need srcset/sizes.
• Descriptors: w (width) descriptors need a sizes attribute and cover fluid, content-width images; x (pixel-density) descriptors suit fixed-size UI images and don’t need sizes.
• sizes is mandatory with w descriptors — omit it and the browser assumes 100vw, often fetching the largest file needlessly. Most common srcset mistake.
• Not a direct ranking signal. Responsive markup doesn’t change what Google indexes — Google indexes the src URL; variants are delivery only. Keep alt textAlt text is the value of the `alt` attribute on an HTML `<img>` element — a short text substitute chosen for the image's purpose and context, not a literal description of what it shows. It makes images accessible to screen-reader users and helps search engines understand images, mainly for image search., filenames, and structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. on the primary src image.
• LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. payoff: oversized images are a top cause of slow LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.; responsive images are LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.’s recommended fix (“Properly size images” audit; fails at a 4KiB gap; RespImageLint helps pick srcset/sizes).
• CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.: srcset alone does nothing for shift — set width/height attributes (or CSS aspect-ratio), paired with height: auto for fluid layouts. Attributes + height: auto is the correct combo, not a conflict.
• Never lazy-load the LCP image; load it eagerly with fetchpriority="high", and keep responsive swaps native (Google won’t load interaction-triggered content).
• Mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost.: same alt textAlt text is the value of the `alt` attribute on an HTML `<img>` element — a short text substitute chosen for the image's purpose and context, not a literal description of what it shows. It makes images accessible to screen-reader users and helps search engines understand images, mainly for image search. and stable image URLs across breakpoints; don’t mint a fresh URL per request.
• Bing: no dedicated responsive-images guidance — justify the work on performance/UX.

Official documentation

Primary-source documentation and developer guidance.

Google — Search

• Google Images best practices — the srcset note, the <picture> fallback-src requirement, same-URL guidance, and the responsive-design rationale.
• Mobile-first indexing best practices — same alt textAlt text is the value of the `alt` attribute on an HTML `<img>` element — a short text substitute chosen for the image's purpose and context, not a literal description of what it shows. It makes images accessible to screen-reader users and helps search engines understand images, mainly for image search. and stable image URLs across mobile and desktop; don’t lazy-load primary content on interaction.

Google — web.dev (developer guidance)

• Learn: Responsive images — srcset complements src; how sizes and media conditions work.
• Learn: The picture element — when you need <picture>, art direction, and “suggestions vs. commands.”
• Optimize Cumulative Layout Shift — width/height attributes, aspect ratio, and height: auto for fluid images.
• Fetch Priority API — fetchpriority="high" for the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. image.

Chrome DevTools / LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.

• Properly size images (uses-responsive-images) — the audit, the 4KiB threshold, and the RespImageLint bookmarklet.

MDN

• Using responsive images in HTML — the reference for srcset, sizes, w/x descriptors, and <picture> syntax.

Quotes from the source

On-the-record statements from Google’s documentation and developer guidance. Where a page exposes the text, the link is a deep link that jumps to the quoted passage.

Google — Image SEOImage SEO is optimizing the images on your pages so search engines can discover, crawl, index, and rank them — in Google Images and visual search, and as part of standard web results. It spans file format, filenames, alt text, compression, responsive markup, structured data, and image sitemaps. docs

• “The srcset attribute allows specifying different versions of the same image, specifically for different screen sizes.” Jump to quote
• “Designing responsive web pages leads to better user experience, since people can access them across a plethora of device types.” Source
• On keeping image URLs stable: “consistently reference the image with the same URL, so that Google can cache and reuse the image.” Jump to quote

Google — Mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost. docs

• “Make sure that the mobile site has the same alt textAlt text is the value of the `alt` attribute on an HTML `<img>` element — a short text substitute chosen for the image's purpose and context, not a literal description of what it shows. It makes images accessible to screen-reader users and helps search engines understand images, mainly for image search. for images as the desktop site.” Jump to quote
• “Don’t use URLs that change every time the page loads for images.” Jump to quote

web.dev — srcset vs. picture

• “Where the srcset attribute gives suggestions to the browser, the picture element gives commands.” Jump to quote

Me — on the CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. fix

• “Reserve the space so that there’s no shift” and the image simply fills it. Jump to quote

Copy-paste responsive image patterns

Three patterns that cover almost every real case. All of them keep a fallback src, explicit width/height (the CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. fix), and identical alt text.

1. Resolution switching — the everyday <img srcset> (my reusable pattern)

<img
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w,
          puppy-2000.jpg 2000w,
          puppy-3000.jpg 3000w"
  sizes="(max-width: 600px) 480px, 1000px"
  width="1000" height="1000"
  alt="Puppy with balloons" />

Pair it with this CSS so the image scales fluidly without causing layout shift:

img {
  max-width: 100%;
  height: auto; /* with width/height attributes set, this prevents CLS */
}

2. Fixed-size image — pixel-density (x) descriptors, no sizes needed

<img
  src="logo.png"
  srcset="logo.png 1x, logo@2x.png 2x"
  width="200" height="60"
  alt="Company logo" />

3. The LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. hero — eager + high priority, and format fallback via <picture>

<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img
    src="hero.jpg"
    width="1200" height="675"
    fetchpriority="high"
    loading="eager"
    alt="Product hero shot" />
</picture>

Rules baked into these:

• Always keep the trailing <img src> — it’s the fallback and the URL Google indexes.
• With w descriptors, sizes is required; without it the browser assumes 100vw.
• With x descriptors, omit sizes.
• Never add loading="lazy" to the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. image (pattern 3) — that delays LCP; use fetchpriority="high" instead.

To find the right srcset/sizes values instead of guessing, run RespImageLint, the bookmarklet Google recommends, over the live page.

Which one do you actually need: srcset/sizes or picture?

Work through the real branch the article draws between resolution switching and art direction / format switching.

Most sites stop at the first branch and never leave srcset/sizes — reach for <picture> only when the image itself needs to change, not just its size.

What not to do

Six concrete mistakes the article calls out, each with why it’s wrong and the fix.

• Forgetting the sizes attribute with w-descriptors. Why it’s wrong: without sizes, the browser assumes the image fills the full viewport width (100vw), so it may fetch your biggest candidate for a slot that renders much smaller. Do instead: always pair w-descriptor srcset with a sizes value that matches how the image actually renders at each breakpoint.
• Dropping the fallback <img src> on <picture>. Why it’s wrong: it’s a spec violation Google explicitly flags, and it’s the URL crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. and Google Images actually indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. — no fallback means no indexable image. Do instead: every <picture> block ends with a plain <img src="...">, never just <source> elements.
• Mismatched width/height ratio versus the actually-served image. Why it’s wrong: the attributes set the reserved aspect ratio; if the real image doesn’t match it, the layout still shifts once the image loads. Do instead: keep the width/height (or aspect-ratio) ratio identical to the image files you’re actually serving across all srcset/<picture> variants.
• Lazy-loading the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. hero image. Why it’s wrong: loading="lazy" delays the fetch of exactly the image Largest Contentful Paint is timing, pushing LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. later for no benefit. Do instead: load the LCP image eagerly with fetchpriority="high", never loading="lazy".
• Regenerating image URLs on every request. Why it’s wrong: it breaks Google’s image cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. and violates the mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost. rule against URLs that change every time the page loads. Do instead: pin stable, consistent URLs per image variant so Google can cache and reuse them.
• Reaching for <picture> when srcset/sizes would do. Why it’s wrong: it’s unneeded complexity — web.dev is explicit that most sites don’t need <picture> at all. Do instead: default to srcset/sizes resolution switching; only add <picture> when you genuinely need a different crop or format per condition.

Common issues

Symptom-first lookup for the two responsive-image problems readers actually hit.

Layout still shifts (CLS) even though srcset is set up

• Symptom: LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. or PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. still reports layout shiftCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. on an image, or you can visually see content jump as the image loads, despite having a working srcset/sizes.
• Likely cause: srcset alone does nothing for layout shift — it only decides which file loads, not how much space to reserve. The image has no width/ height attributes (or CSS aspect-ratio), so the browser can’t allocate space until the file starts downloading and its dimensions are known.
• Fix + confirm: Add explicit width and height attributes to the <img> (or set CSS aspect-ratio), and pair them with height: auto in CSS so the image still scales fluidly. Confirm by re-running the CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. check (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. or a live CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. check) and watching for the shift to disappear — the reserved box should now hold its size before the image finishes loading.

Lighthouse flags “Properly size images” / an oversized image is loading

• Symptom: The Lighthouse “Properly size images” audit lists one or more images with wasted bytes, or a page feels slow to reach its Largest Contentful PaintLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. even though the image itself looks fine.
• Likely cause: The rendered size of the image is at least 4KiB smaller than the actual file being served — commonly because there’s no srcset at all, or sizes is missing so the browser defaulted to 100vw and pulled the largest candidate for a small slot.
• Fix + confirm: Add (or correct) srcset with appropriately sized candidates and a sizes value matching the real rendered width; run RespImageLint to check the values instead of guessing. Confirm by re-running the Lighthouse “Properly size images” audit and checking the flagged image no longer appears (or its potential savings drop below the 4KiB threshold).

Cheat sheet: descriptors, picture vs. srcset, and the CLS/LCP rules

Validation tests

Pass/fail checks that confirm a responsive-image change actually took effect.

Properly-sized images ship correctly

Test to run: Run the LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. “Properly size images” audit (Chrome DevTools > LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. > Performance, or PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.) on the page you just updated. Expected result: The image you fixed no longer appears in the audit’s flagged list, or its potential savings drop below the 4KiB gap threshold. Failure interpretation: If it’s still flagged, either srcset candidates are still too large for the rendered size, or sizes is missing/wrong and the browser is still defaulting to 100vw. Monitoring window: Immediate — re-run right after deploying the change. Rollback trigger: The audit still flags the same image with unchanged potential savings after confirming sizes matches the real rendered width.

srcset/sizes values are actually optimal

Test to run: Run RespImageLint (the bookmarklet Google recommends) against the live page. Expected result: No warnings about oversized candidates or a missing/incorrect sizes value. Failure interpretation: A warning means either a candidate is unnecessarily large for its breakpoint or sizes doesn’t match the container’s real rendered width. Monitoring window: Immediate, on the live URL after deploy. Rollback trigger: RespImageLint keeps flagging the same image after you’ve corrected the sizes value.

The browser actually selected the candidate you expected

Test to run: Passing the Lighthouse/RespImageLint checks confirms your markup is valid — it doesn’t confirm the browser picked the file you intended at a given viewport. Load the page at the breakpoint you care about, open DevTools, select the <img>, and check its currentSrc property in the console ($0.currentSrc in Chrome/Firefox DevTools) — MDN’s own example does exactly this: comparing currentSrc against the expected filename to confirm which candidate loaded. Cross-check against the Network tab to see which file was actually requested. Repeat at your narrow and wide breakpoints, and at 1x and 2x device pixel ratio if you emulate it. Expected result: currentSrc matches the candidate file you’d expect for that viewport width and pixel density, and the Network tab shows only that file was fetched. Failure interpretation: If currentSrc returns a candidate bigger or smaller than expected, either the sizes value doesn’t match the image’s actual rendered CSS width (see “Why sizes matters” in the Advanced tab) or a srcset descriptor is wrong. Note that browser selection is implementation-defined — the HTML Standard leaves the exact choice among valid candidates to the browser (density, zoom, and network conditions can all factor in), so don’t expect byte-identical behavior across browsers; check for “reasonable candidate,” not one fixed answer. Monitoring window: Immediate — check per breakpoint right after deploying. Rollback trigger: currentSrc keeps returning an oversized candidate at a narrow viewport after you’ve corrected sizes to match the real rendered width.

No layout shift from the image

Test to run: Check Cumulative Layout ShiftCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. for the page — Lighthouse’s CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. score, or a live CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program./PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. field-data check for the URL. Expected result: CLS attributable to the image drops to (near) zero once width/height (or aspect-ratio) are set. Failure interpretation: Persistent shift usually means the width/height ratio doesn’t match the actual image being served, or the attributes are missing entirely. Monitoring window: Lab data is immediate; field dataPerformance metrics captured from real users, not lab tests. (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) needs about 28 days to accumulate a trustworthy trend. Rollback trigger: CLS in field data doesn’t improve after 28 days despite the lab check passing — revisit whether the served image ratio actually matches the reserved box.

Test yourself: Responsive images

Five quick questions on srcset, sizes, <picture>, and how responsive images affect SEO. Pick an answer for each, then check.

Changelog