Responsive Image Test

What is it?

A responsive image check evaluates whether the images on your page are served at dimensions appropriate for the user's viewport. Serving an image significantly larger than the size at which the browser actually renders it wastes bandwidth, slows page load, and forces the browser to scale the asset down before display. On a mobile connection, this is one of the most common causes of poor loading performance, and it is also one of the easiest issues to fix once you know which images are oversized.

Why image sizing has an outsized performance impact

Images typically account for the majority of the bytes on a modern web page. A single high-resolution photo served unscaled to a mobile viewport can outweigh all the HTML, CSS, and JavaScript on the page combined. Properly sized images therefore have an outsized effect on Core Web Vitals, especially Largest Contentful Paint (LCP), where the hero image is often the metric-defining element. Pages that ship images at appropriate dimensions consistently score better on Lighthouse and PageSpeed Insights, and the improvement translates directly into better real-world load times for users on slower connections.

The modern way to handle responsive images is the srcset and sizes attributes, which let the browser pick the best variant from a list you provide. With a few lines of HTML, you can ship a 400-pixel image to a phone and a 1600-pixel image to a desktop without writing any JavaScript. Most modern frameworks and CMS platforms include components or helpers that generate these attributes automatically.

Common mistakes worth checking

Original camera or stock-photo files uploaded as-is, often six or eight times larger than they need to be.
No srcset, leaving the browser with a single source no matter the viewport.
Hero images sized for ultra-wide displays served to phone-sized screens.
Background images set in CSS without responsive sources, which require image-set() or media queries to handle properly.
Lazy-loading the hero image, which delays LCP unnecessarily; lazy-loading should apply only below the fold.

This test reports which images are oversized for their actual rendered dimensions and by how much. The fix guide below walks through generating responsive variants, configuring srcset and sizes, and using the image components built into the major content management systems and frameworks.

Pass rate:

Top 100 websites: 29%
This value indicates the percent of top 100 most visited websites in the US that pass this test (in the past 12 months).
All websites: 23%
This value indicates the percent of all websites analyzed in SEO Site Checkup (500,000+) in the past 12 months.

Pass rates of Top 100 US websites
2021	38%
2022	31%
2023	28%
2024	29%

100

How do I fix it?

This test fails when one or more images on the page are served at dimensions significantly larger than the size at which the browser actually renders them. Fixing this issue means resizing the source files (or serving responsive variants) so the bytes downloaded match the pixels actually displayed. The result is faster page loads, lower data usage, and better Core Web Vitals scores.

Example

<img
  src="/images/hero-800.jpg"
  srcset="/images/hero-400.jpg 400w,
          /images/hero-800.jpg 800w,
          /images/hero-1600.jpg 1600w"
  sizes="(max-width: 640px) 100vw, 800px"
  alt="Marathon runners at sunrise"
  width="800" height="450">

Where to make the change

Raw HTML: use srcset and sizes to let the browser pick the right variant for the user's viewport. Always include intrinsic width and height attributes.
WordPress: WordPress generates multiple image sizes automatically. Use the the_post_thumbnail() helper or the block editor's image block, both of which emit responsive srcset markup.
Shopify: use the image_url Liquid filter with size parameters (for example {{ image | image_url: width: 800 }}) and pair with image_tag to emit a responsive image.
Wix or Squarespace: both platforms generate responsive variants automatically; this issue is typically caused by uploading a deliberately oversized image.
Headless or framework sites: use the framework's image component (for example next/image or astro:assets), which generates responsive variants and lazy-loads off-screen images.

Common causes and how to resolve them

Original camera or stock-photo file uploaded as-is: a 6000-pixel-wide JPEG rendered in a 400-pixel column wastes most of the bytes. Resize the source or generate responsive variants.
No srcset: the browser has no choice but to use the single source. Add multiple variants so mobile users get smaller files.
Hero images sized for ultra-wide displays: if your largest layout is 1600 pixels, do not ship a 4000-pixel original.
Background images set in CSS without responsive sources: use the image-set() CSS function or media queries to swap in different image files at different breakpoints.

Best practices

Generate variants at common widths: 400, 800, 1200, and 1600 pixels covers most viewports cleanly.
Always set width and height: intrinsic dimensions let the browser reserve space and avoid layout shift, helping CLS.
Lazy-load off-screen images: add loading="lazy" to images below the fold so the browser only downloads them when needed.
Pair with modern formats: resizing alone is good; resizing and serving WebP or AVIF compounds the savings.