Should we really serve low-resolution images for slow connections?

Why does Google emphasize low-resolution images?

Mueller's statement is based on a simple logic: users with slow connections should never face a void. When an image fails to load, the browser displays a broken white square — terrible for UX and disastrous for behavioral signals.

For years, Google has valued sites that adapt to real network conditions. The issue is that many sites either serve a single HD image or nothing at all. There's no middle ground. And that's where it gets stuck: a user on 3G who waits 15 seconds for a 2MB hero image ends up leaving the site.

What does the 'srcset' attribute really change?

The 'srcset' attribute allows you to declare multiple versions of the same image with their respective resolutions. The browser automatically selects the most appropriate version based on viewport width, pixel density, and estimated connection speed.

Unlike a simple tag, srcset gives the browser some leeway. It can decide to load a 480px version instead of a 1920px version if the user is on mobile using 3G. Less bandwidth consumed, faster loading, preserved UX. However, in practice, many CMSs do not automatically generate these variants — or generate them poorly.

Does this recommendation apply to all types of images?

No, and that's an essential nuance. Decorative images (CSS backgrounds, non-critical illustrations) can be lazy-loaded or even omitted on mobile without issue. In contrast, content images — e-commerce products, article visuals, explanatory diagrams — must be served, even in a degraded version.

Google never explicitly states where to draw the line. But the intent is clear: it's better to have a blurry image than no image at all. Mobile-first crawling takes these signals into account, and a site that consistently shows image holes on mobile sends a negative signal regarding user experience.

• srcset allows the browser to automatically choose the right resolution based on network conditions and the viewport.
• Critical content images must always have a low-resolution backup version.
• Google values sites that adapt to slow connections, which indirectly impacts ranking through UX signals.
• Lazy-loading and srcset are not incompatible — they address two different issues (timing vs. weight).
• A site that displays image holes on mobile sends a signal of degraded experience to the engine.

Is this statement consistent with real-world observations?

Yes, but with a significant caveat: Google does not directly penalize a site that serves only HD images. What gets penalized is the impact on Core Web Vitals — particularly LCP (Largest Contentful Paint) and CLS (Cumulative Layout Shift). If an image takes 8 seconds to load and shifts the entire layout, you're taking a hit in rankings.

Let’s be honest: Mueller doesn't say, “if you don’t use srcset, you will drop.” He says, “if you show nothing, it’s worse than showing a degraded version.” An important nuance. What matters is the user perception and the metrics that stem from it. A site with HD images that loads in 1.5 seconds has no problem — even without srcset.

What nuances should be added?

Mueller's advice assumes that showing nothing = bad UX. This is true in 90% of cases. However, there are contexts where an unloaded image isn't a tragedy. For example, a blog with decorative illustrations at the end of an article can afford to lazy-load without a backup version.

Another point: srcset is not a magic solution. If you generate 5 image variants but your server takes 2 seconds to send them, the problem remains. The real optimization is CDN + modern compression (WebP, AVIF) + srcset + intelligent lazy-loading. Taking one lever is never enough. [To verify]: Does Google claim that srcset directly impacts ranking, or only through Core Web Vitals? Mueller does not explicitly say this — and it’s typical of this kind of vague declaration.

In which cases does this rule not apply?

If your site is 100% desktop B2B with a fiber optic audience in business, this recommendation is not urgent. The same goes for a super-light showcase site with 3 images in total. The implementation effort isn't worth it.

On the other hand, for mobile-first e-commerce, online news, or consumer SaaS, this is a priority project. The majority of the traffic comes from mobile, often on unstable networks. Not adapting images means letting 20-30% of visitors slip away before they've even seen a product. And Google picks this up through behavioral signals — bounce rate, time on page, scroll depth.

What should you do to implement srcset?

First step: audit the critical images on your site — those that appear in the initial viewport, product visuals, hero images. These directly impact LCP and UX. For each, you should generate at least 3 variants: a mobile version (480-640px), a tablet version (768-1024px), and a desktop version (1920px+).

Then, you integrate srcset into your tags. Basic example: <img src="image.jpg" srcset="image-480.jpg 480w, image-768.jpg 768w, image-1920.jpg 1920w" sizes="(max-width: 600px) 480px, (max-width: 1200px) 768px, 1920px" alt="...">. The browser automatically chooses the correct variant. If your CMS does not generate these variants, you'll need to script the automatic generation — or use a dedicated plugin (be wary of poorly optimized plugins that create more problems than they solve).

What mistakes should be absolutely avoided?

Mistake #1: generating low-resolution variants without modern compression. A 480px image in unoptimized JPEG can be as heavy as a 1920px image in WebP. Always couple srcset with WebP/AVIF and aggressive compression.

Mistake #2: lazy-loading above-the-fold images. If your hero banner is lazy-loaded, your LCP will skyrocket — regardless of the available resolutions. Always systematically exclude critical images from lazy-loading. Mistake #3: not testing on real mobile devices with network throttling. What loads in 1 second on your office fiber might take 10 seconds on unstable 3G. Use Chrome DevTools in “Slow 3G” mode to check real UX.

How can I verify that my site is compliant?

Test with PageSpeed Insights and look at the LCP score in mobile mode. If you are above 2.5 seconds, your images are probably too heavy. Next, verify that srcset is present on critical images with the “Elements” tab of Chrome DevTools. If srcset is missing or misconfigured, you'll see the browser consistently loading the HD version.

Also, use WebPageTest with 3G throttling to simulate real conditions. Compare the total weight of images loaded on mobile vs. desktop. If the delta is small, srcset is not doing its job. Finally, check with Search Console that your mobile bounce rate is not unusually high — a potential sign of degraded UX due to images that fail to load.

• Generate at least 3 variants per critical image (mobile, tablet, desktop)
• Implement srcset with the sizes attribute to guide the browser
• Combine with WebP/AVIF and aggressive compression
• Exclude above-the-fold images from lazy-loading
• Test with PageSpeed Insights and WebPageTest under 3G throttling
• Audit mobile bounce rate in Search Console