Add srcset and sizes to Fix Responsive Images
Your audit found images that ship one fixed-size file to every visitor instead of using the srcset and sizes attributes. Adding them lets the browser pick the smallest image that still looks sharp on each screen, cutting wasted bytes on mobile and helping your Largest Contentful Paint. This is a notice, not an error, but on image-heavy pages it is one of the highest-leverage speed fixes you can make.
What this means
One or more <img> tags on the page serve a single fixed-size image to every device through a plain src, with no srcset (and usually no sizes) offering smaller alternatives.
srcset lists multiple versions of the same image at different widths, each tagged with a width descriptor like 480w or 1200w. sizes tells the browser how wide the image will actually render at different viewport widths. Together they let the browser decide up front: it reads the layout width from sizes, multiplies by the device pixel ratio, then picks the smallest file in srcset that still covers that need.
Without them, a phone with a 400px-wide slot downloads the same large image a desktop gets. The browser scales it down so it still looks fine, but the visitor already paid for the full-resolution file. On a slow mobile connection that is often hundreds of kilobytes wasted per image.
The severity is a notice. Nothing is broken and the page renders correctly. This is a performance and bandwidth optimization, and on image-heavy pages it is usually worth doing.
Why it matters
On most pages the main image is the Largest Contentful Paint (LCP) element, so how fast it loads directly shapes a Core Web Vitals metric Google uses as a page-experience signal. Google's target for a good LCP is under 2.5 seconds. Serving a right-sized file instead of an oversized one is one of the most reliable ways to pull that number down, especially on mobile where connections are slower and viewports are smaller.
The savings compound. Right-sizing an image can strip a large share of its bytes on a phone compared with serving one desktop-width file everywhere, and the gap widens on image-heavy pages. Fewer bytes means faster paint, less data burned on capped mobile plans, and lower bounce risk on the devices where most traffic now lives.
There is also an AI-visibility angle. Answer engines like Google AI Overviews, Perplexity, and ChatGPT crawl the same pages and weigh load performance when deciding what to fetch and render. A leaner, faster-rendering page is cheaper for a crawler to process and more likely to finish rendering before any timeout. Responsive images will not make or break AI citations on their own, but they help keep the page fast and crawler-friendly, which supports the rest of your AEO and GEO work.
How to fix it
- 1
Generate the resized versions first
srcset only works if the smaller files exist. Create a few widths of each image, commonly 480, 800, and 1200 plus the original, and use a modern format like WebP or AVIF while you are at it. Most CMS platforms and image CDNs do this automatically on upload. For a static site, a build step (a bundler plugin, Sharp, or ImageMagick) can batch-generate them. Three or four steps cover almost every screen, so do not hand-crop dozens of sizes.
- 2
Add srcset with width descriptors
List each file with its real pixel width using the
wdescriptor, for examplesrcset="photo-480.jpg 480w, photo-800.jpg 800w, photo-1200.jpg 1200w". Usewrather than the1x/2xdensity syntax whenever the image changes size across viewports, which is nearly always the case for content and hero images. Keep the plainsrcas a fallback for old browsers. The browser reads the widths and picks the best match; you never hardcode which file goes to which device. - 3
Add a matching sizes attribute
Without
sizes, the browser assumes the image fills the full viewport width (100vw) and usually over-downloads. Tell it the truth about your layout. For an image that is full-width on mobile but capped at 800px on desktop, usesizes="(max-width: 800px) 100vw, 800px". Match these values to how your CSS actually sizes the image. Gettingsizesright is what turns srcset from a nice idea into real byte savings. - 4
Set width and height, and get the LCP image right
Always include intrinsic
widthandheightattributes so the browser reserves space and avoids layout shift (CLS). For your main above-the-fold image, do not lazy-load it: leave loading eager and addfetchpriority="high"so it downloads early. Reserveloading="lazy"for below-the-fold images. A lazy-loaded LCP image is a common self-inflicted speed regression. - 5
Let your platform do it, then verify
On most managed platforms this is a setting, not hand-written markup (see the platform notes). After enabling it, re-check a real page. Open DevTools, inspect the image in the Elements panel, and confirm
srcsetandsizesare present, then narrow the viewport and watch the Network tab load a smaller file. Re-run the audit to clear the notice.
Example
<img
src="photo-800.jpg"
srcset="
photo-480.jpg 480w,
photo-800.jpg 800w,
photo-1200.jpg 1200w
"
sizes="(max-width: 800px) 100vw, 800px"
width="1200"
height="800"
alt="Descriptive alt text for the image"
loading="lazy"
decoding="async"
>
<!-- Above-the-fold LCP image: prioritize it, do not lazy-load -->
<img
src="hero-800.jpg"
srcset="hero-480.jpg 480w, hero-800.jpg 800w, hero-1600.jpg 1600w"
sizes="100vw"
width="1600"
height="900"
alt="Hero image description"
fetchpriority="high"
>A responsive content image: multiple widths in srcset, a sizes attribute matching the layout, explicit dimensions to prevent layout shift, and lazy loading. For your LCP image, drop loading="lazy" and add fetchpriority="high" (second block).
Platform-specific steps
Core adds srcset and sizes automatically to library images since v4.4, and neither Yoast nor Rank Math changes that. If the notice appears, find the specific images missing srcset: they are typically hardcoded in theme templates, added through a page builder like Elementor or Divi, or pasted as raw HTML. Fix theme images by switching from a bare <img src> to wp_get_attachment_image(), which outputs responsive markup. For builder images, use the builder's native image widget rather than a custom HTML block. An optimization plugin such as ShortPixel, Imagify, or EWWW can also generate WebP/AVIF sizes to feed the srcset.
Shopify's image_url and image_tag Liquid filters output responsive markup. In your theme's Liquid, use image_tag with a widths parameter, for example {{ image | image_url: width: 1200 | image_tag: widths: '480, 800, 1200', sizes: '(max-width: 749px) 100vw, 700px' }}. Shopify's CDN resizes on the fly, so you do not pre-generate files. The plain src usually hides in custom sections or hardcoded <img> tags in older themes, so check those.
Both serve responsive images automatically for content added through their editors and image blocks, and you cannot hand-edit the markup. If this is flagged, it is almost always an image injected through a custom code or embed block, or a third-party widget. Move those images into a native image element so the platform's own responsive delivery takes over. There is no manual srcset to write here.
For hand-written HTML, add srcset and sizes yourself (see the code example) and generate the resized files in your build. In Next.js, the next/image component outputs srcset, sizes, width, and height automatically and serves WebP/AVIF; set the sizes prop to match your layout and use the priority prop on the LCP image instead of lazy loading. For other frameworks, an image CDN like Cloudflare Images, imgix, or Cloudinary, or a Sharp-based build step, generates the widths without manual cropping.
Frequently asked
srcset is the menu of image files and their real widths, for example photo-800.jpg 800w. sizes tells the browser how wide the image will render on the page at different viewport widths, for example (max-width: 600px) 100vw, 50vw. The browser reads sizes to work out the needed display width, then picks the smallest srcset file that covers it. You almost always want both: srcset alone makes the browser assume a display width of 100vw, which often over-downloads.
Usually not. Since WordPress 4.4, core automatically adds srcset and sizes to images inserted through the media library, using the thumbnail sizes it generates on upload (WordPress 6.7 also added sizes="auto" for lazy-loaded images). If this issue is still flagged, the likely culprits are images hardcoded into a theme template, added through a page builder, pasted as raw HTML, or stripped by a plugin. Check those specific images rather than assuming core is broken.
Use plain srcset and sizes on an <img> for resolution switching, where you serve the same image at different sizes. Use the <picture> element with <source> tags for art direction (a differently cropped image on mobile versus desktop) or to offer modern formats like AVIF or WebP with a JPEG fallback. For the common case this audit flags, an <img> with srcset and sizes is simpler and correct.
No. srcset gives the browser sharper options, not worse ones. On a high-DPI phone it can pick a higher-resolution file to stay crisp; on a small low-DPI screen it picks a smaller one because the extra pixels would not be visible anyway. As long as your largest srcset entry matches the biggest size the image is ever displayed at, quality holds up everywhere while smaller devices save bandwidth.
Indirectly, through speed. srcset is not itself a ranking signal, but it cuts wasted bytes and speeds up your Largest Contentful Paint, and LCP is part of Core Web Vitals, which Google uses as a page-experience signal. The effect is strongest on mobile and on image-heavy pages. Since it is a notice-level issue, treat it as an optimization that supports your other speed work, not an emergency.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.