A site can have clean HTML, minimal JavaScript, optimized fonts, and efficient CSS - and still load slowly on mobile because someone uploaded a 2400px-wide JPEG for the hero section and left it there. Images are consistently the single largest contributor to page weight, and mobile users pay for that weight in both load time and data usage. The fix is well-documented, the browser support is excellent, and most teams still are not implementing it fully.
The issue is not ignorance of the problem - most developers know that oversized images hurt performance. The issue is that the correct implementation of responsive images involves three separate mechanisms that interact with each other, and partial implementations leave most of the performance benefit unrealized.
The Three-Part Solution
Part 1: srcset for Resolution Switching
The srcset attribute tells the browser what versions of an image are available and at what widths. The browser then chooses the most appropriate version based on the current viewport width and the device's pixel density.
<img
src="product-800.jpg"
srcset="product-400.jpg 400w,
product-800.jpg 800w,
product-1200.jpg 1200w,
product-1600.jpg 1600w"
alt="Product overview showing key features"
width="800"
height="600"
>
Without the sizes attribute (covered below), the browser defaults to assuming the image will render at 100% of the viewport width. This is often wrong - a product image in a three-column grid on desktop renders at roughly 33% of the viewport width, not 100%. The browser will still pick a reasonable option from srcset without sizes, but it will not be the optimal one.
The width and height attributes are not optional - they tell the browser how much space to reserve for the image before it loads, preventing layout shift. This directly improves Cumulative Layout Shift (CLS), one of the Core Web Vitals metrics Google uses in ranking calculations.
Photo by Karub on Pexels
Part 2: sizes for Layout Context
The sizes attribute tells the browser how wide the image will actually render at different viewport widths. Without this information, the browser cannot calculate the optimal source to request because it does not know whether the image occupies the full viewport width, half of it, or a fixed pixel value.
<img
src="product-800.jpg"
srcset="product-400.jpg 400w,
product-800.jpg 800w,
product-1200.jpg 1200w,
product-1600.jpg 1600w"
sizes="(max-width: 480px) 100vw,
(max-width: 768px) calc(100vw - 2rem),
(max-width: 1200px) 50vw,
400px"
alt="Product overview showing key features"
width="800"
height="600"
>
This tells the browser: on screens narrower than 480px, the image takes the full viewport width; on screens up to 768px, it takes the full width minus 2rem of padding; on screens up to 1200px, it takes half the viewport; on larger screens, it renders at a fixed 400px. With this information, the browser can select the minimum file that will look sharp at each size.
The MDN documentation on responsive images covers the srcset and sizes interaction in depth, including the calculation the browser uses to select the appropriate source.
Part 3: Modern Formats with the picture Element
JPEG and PNG have been the default image formats for web use for decades. WebP and AVIF offer significantly better compression at equivalent visual quality - WebP typically reduces file size by 25-35% compared to JPEG, and AVIF reduces it further still. The <picture> element lets you serve these modern formats to browsers that support them while falling back to JPEG for browsers that do not.
<picture>
<source
type="image/avif"
srcset="product-400.avif 400w, product-800.avif 800w, product-1200.avif 1200w"
sizes="(max-width: 768px) 100vw, 50vw"
>
<source
type="image/webp"
srcset="product-400.webp 400w, product-800.webp 800w, product-1200.webp 1200w"
sizes="(max-width: 768px) 100vw, 50vw"
>
<img
src="product-800.jpg"
srcset="product-400.jpg 400w, product-800.jpg 800w, product-1200.jpg 1200w"
sizes="(max-width: 768px) 100vw, 50vw"
alt="Product overview showing key features"
width="800"
height="600"
>
</picture>
The browser reads the source elements from top to bottom and uses the first one it supports. AVIF gets priority, then WebP, then JPEG as the fallback. The caniuse data for WebP shows support above 97% globally, and AVIF support has crossed 90% in modern browsers.
The Automation Problem
Manually generating four format variants at four size variants for every image on a site is not sustainable for content-heavy projects. The right approach is to automate image processing as part of the build pipeline or at the content management layer.
Cloudinary, Imgix, and Cloudflare Images are CDN-based services that handle format conversion, resizing, and delivery automatically. You upload a source image and the service generates appropriate derivatives on-demand based on URL parameters or automatic optimization. The Google developer documentation on image optimization covers the principles behind this approach.
For teams managing image processing at the build layer, Sharp is a Node.js image processing library that generates optimized variants efficiently. ImageMagick provides equivalent functionality in server-side and CLI contexts.
The lazy Attribute: Deferring Off-Screen Images
Beyond serving the right image size, there is a simpler win available for below-the-fold images: native lazy loading. Adding loading="lazy" to an img element tells the browser to defer loading that image until it is near the viewport, rather than loading all images as soon as the HTML is parsed.
<!-- Images below the fold do not need to load immediately -->
<img
src="article-inline-800.jpg"
srcset="article-inline-400.jpg 400w, article-inline-800.jpg 800w"
sizes="(max-width: 768px) 100vw, 50vw"
alt="Diagram showing responsive image size selection logic"
width="800"
height="450"
loading="lazy"
>
The loading="lazy" attribute has broad browser support and requires no JavaScript or external libraries. For pages with multiple inline images - articles, product listings, portfolio pages - lazy loading significantly reduces the initial page payload and improves LCP for the content above the fold.
One important exception: do not apply loading="lazy" to the largest contentful element or any image above the fold. The browser needs to load those immediately for LCP. Lazy loading is for images the user has not yet scrolled to.
"Image weight is the single biggest performance win most sites leave on the table. We regularly cut 40-60 percent off total page weight just by implementing proper srcset with a CDN in front of it - without touching a single line of application code." - Dennis Traina, 137Foundry
Photo by AS Photography on Pexels
Practical Starting Point
If you are working on a site that does not yet have responsive images, the fastest path to improvement is not a full pipeline implementation - it is auditing the current images with PageSpeed Insights or WebPageTest to identify the largest offenders, then implementing srcset and sizes on those specific images first. The Pareto distribution applies strongly to image weight: typically 20% of images account for 80% of the wasted bytes.
For a complete look at how mobile performance decisions fit into mobile-first design as a whole - including Core Web Vitals targets, fluid typography, and touch-first interaction design - the guide to mobile-first web design connects these technical details to the broader design approach.
137Foundry handles image optimization as a standard part of web development projects, integrating the three-part responsive image system alongside CDN configuration so performance does not degrade as content grows.
The responsive image specification has been supported in all major browsers since 2016. There is no longer a compatibility reason to avoid it. The only remaining barrier is implementation effort - and for most sites, addressing the largest image offenders takes an afternoon and measurably improves both page speed and search rankings.
Top comments (0)