You're sending a 2400px image to a 375px phone. Here's ...

Your product page has a hero image that's 2400 pixels wide. It looks great on a 27-inch monitor. It also loads on every phone that visits the page, where it displays at 375 pixels wide. The user downloaded 850KB of image data to display something that could have been 90KB.

Responsive images fix this. The srcset and sizes attributes on the <img> tag let the browser choose the right image resolution for the current viewport and screen density. Without them, every device gets the same file regardless of whether it can use those pixels.

How srcset works

The srcset attribute lists multiple versions of the same image at different widths:

<img
  srcset="hero-400.webp 400w,
          hero-800.webp 800w,
          hero-1200.webp 1200w,
          hero-1600.webp 1600w,
          hero-2400.webp 2400w"
  sizes="(max-width: 768px) 100vw, (max-width: 1200px) 75vw, 50vw"
  src="hero-1200.webp"
  width="2400" height="1350"
  alt="Product overview showing the dashboard interface">

The sizes attribute tells the browser how wide the image will display at different viewport sizes. The browser combines this with the device pixel ratio (1x, 2x, 3x) to calculate the ideal image width and picks the closest match from srcset.

On a 375px phone at 2x density, the browser calculates: 375px * 2 = 750px. It picks hero-800.webp from the srcset. That 800px image at quality 80 in WebP might be 85KB instead of the 850KB full-resolution version. Same visual quality at the display size. 90% less data transferred.

The real cost of oversized images

Images are the single largest contributor to page weight on the median web page. HTTP Archive data from 2024 shows the median page transfers 1.2MB of images. On mobile, where bandwidth is constrained and metered, that weight translates directly to load time and data cost.

A user on a $30/month mobile plan in the US gets about 5GB of data. A single page visit with 2MB of oversized images uses 0.04% of their monthly allowance. That sounds small until you consider they visit dozens of pages per session and hundreds of sites per month. The aggregate waste adds up, and users on limited plans learn to avoid image-heavy sites.

For site owners, the cost is in Core Web Vitals. LCP (Largest Contentful Paint) is usually determined by the largest image above the fold. An 850KB hero image takes 1.4 seconds to download on a 5 Mbps connection. An 85KB optimized version takes 0.14 seconds. That difference alone can move your LCP from "poor" to "good."

What most sites get wrong

No srcset at all. The most common case. The site generates one image size and every device gets it. CMS platforms often do this by default unless you configure their image processing pipeline.

srcset without sizes. If you provide srcset but omit sizes, the browser assumes sizes="100vw", which means it thinks the image fills the entire viewport width. On desktop, where the image might only fill 50% of the viewport, the browser picks an image twice as large as needed.

Wrong dimensions in width/height. The width and height attributes on <img> aren't just for sizing. They tell the browser the aspect ratio so it can reserve space before the image loads, preventing layout shift. Setting these to CSS pixels (not natural pixels) matches the intrinsic size attribute specification.

Art direction ignored. Some images need different crops for different viewport sizes, not just different resolutions. A wide landscape banner on desktop might need a square crop on mobile to remain visually effective. The <picture> element handles this:

<picture>
  <source media="(max-width: 768px)" srcset="hero-mobile-square.webp">
  <source media="(max-width: 1200px)" srcset="hero-tablet.webp">
  <img src="hero-desktop.webp" width="2400" height="900" alt="...">
</picture>

What the tool checks

The Responsive Image Srcset Audit scans your page and reports:

Images missing srcset that are larger than 100KB
Images with srcset but missing sizes attribute
Natural dimensions versus displayed dimensions (flagging where natural is 2x+ larger than displayed)
Missing width and height attributes
Format opportunities (JPEG/PNG where WebP/AVIF would be significantly smaller)
Total wasted bytes from serving oversized images

The tool calculates the potential data savings per image and across the entire page, showing exactly how much bandwidth your mobile users are wasting.

Building responsive images into your workflow

Static site generators: Most (Eleventy, Hugo, Gatsby) have image plugins that generate multiple sizes at build time. Configure once, apply everywhere.

WordPress: Use the built-in responsive image support (default since 4.4) or a plugin like ShortPixel that generates WebP variants at multiple sizes.

Manual workflow: Generate 4-5 sizes (400, 800, 1200, 1600, 2400 wide), convert to WebP, and write the srcset by hand. For a site with 50 images, this takes an afternoon and saves bandwidth permanently.

The key insight is that responsive images are a one-time setup cost with permanent returns. Every page view after the setup benefits from reduced transfer size, faster load times, and better Core Web Vitals.

If you're building a lean web presence where performance directly impacts revenue, The $97 Launch ($9.99 on Kindle) covers the image pipeline and other optimizations that make small sites load like they have a full infrastructure team behind them.

Fact-check notes and sources

HTTP Archive median image weight: HTTP Archive, State of Images
srcset specification: HTML Standard, img element
WebP compression savings: Google Developers, WebP
LCP image impact: web.dev, Optimize Largest Contentful Paint
WordPress responsive images (4.4+): WordPress Developer Resources, Responsive Images

You're sending a 2400px image to a 375px phone. Here's what that costs.