# You're sending a 2400px image to a 375px phone. Here's what that costs.
Responsive images with srcset and sizes serve the right resolution to each device. Without them, mobile users download images 5-10x larger than needed.
Author: J.A. Watte
Published: April 30, 2026
Source: https://jwatte.com/blog/blog-tool-responsive-image/
---
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 `` 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:
```html
```
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 `` 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 `` element handles this:
```html
```
## What the tool checks
The [Responsive Image Srcset Audit](/tools/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](https://httparchive.org/reports/state-of-images)
- srcset specification: [HTML Standard, img element](https://html.spec.whatwg.org/multipage/embedded-content.html#attr-img-srcset)
- WebP compression savings: [Google Developers, WebP](https://developers.google.com/speed/webp)
- LCP image impact: [web.dev, Optimize Largest Contentful Paint](https://web.dev/articles/optimize-lcp)
- WordPress responsive images (4.4+): [WordPress Developer Resources, Responsive Images](https://developer.wordpress.org/apis/responsive-images/)
## Related reading
- [LCP image candidate audit](/blog/blog-tool-image-lcp-candidate/) — above-fold image loading priority
- [Image sitemap extension audit](/blog/blog-tool-image-sitemap/) — Google Images discovery
- [Compression codec audit](/blog/blog-tool-compression-codec/) — transfer encoding optimization
- [Response size budget audit](/blog/blog-tool-response-size-budget/) — total page weight
- [CrUX field data](/blog/blog-tool-crux-field-data/) — real-user performance metrics
*This post is informational, not performance-consulting advice. Tool mentions are descriptive. No affiliation with browser vendors is implied.*
---
Canonical HTML: https://jwatte.com/blog/blog-tool-responsive-image/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/blog-tool-responsive-image.webp
```
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 `