A crisp image on a standard display turns blurry on a Retina screen.
Physics are straightforward. Retina displays pack twice the pixels into the same physical space. An image sized for standard displays gets stretched to cover those extra pixels. Stretching blurs.
Solutions are equally straightforward in concept: provide higher-resolution images. The complexity is in the implementation. Serving appropriate images to diverse devices without destroying bandwidth or performance requires strategy.
Understanding Device Pixel Ratio
Device pixel ratio measures screen density.
A standard display has a ratio of 1. One CSS pixel equals one device pixel. A 100px image uses 100 physical pixels.
A 2x Retina display has a ratio of 2. One CSS pixel equals four device pixels (2 wide by 2 tall). A 100px CSS image needs 200 physical pixels to appear sharp.
A 3x display, common on high-end phones, has a ratio of 3. One CSS pixel equals nine device pixels. A 100px CSS image needs 300 physical pixels.
Math multiplies quickly. A 500×300 hero image needs 1000×600 for 2x displays and 1500×900 for 3x displays. File sizes grow proportionally.
Not all users have high-DPI displays. Serving 3x images to everyone wastes bandwidth for standard display users. Match image resolution to device capability.
Srcset for Resolution Switching
Srcset lets browsers choose appropriate images.
<img src="image.jpg"
srcset="image.jpg 1x,
image-2x.jpg 2x,
image-3x.jpg 3x"
alt="Description">Browsers examine their device pixel ratio, select the matching image, and download only that version. Standard displays get the 1x image. Retina displays get 2x. High-end phones get 3x.
Src provides fallback for browsers that don’t support srcset. This is rarely needed now but maintains compatibility.
Width descriptors offer more flexibility than pixel ratio descriptors:
<img src="image-800.jpg"
srcset="image-400.jpg 400w,
image-800.jpg 800w,
image-1200.jpg 1200w"
sizes="(max-width: 600px) 100vw, 50vw"
alt="Description">W values indicate image width in pixels. The sizes attribute tells browsers how large the image will display. Browsers calculate which image provides appropriate resolution for the display context.
Picture Element for Art Direction
Sometimes different display contexts need different images entirely, not just different resolutions.
A wide hero image on desktop might not work on mobile. Important subject matter might get cropped or too small. Different crops or compositions serve different viewports better.
Picture elements enable art direction:
<picture>
<source media="(max-width: 600px)" srcset="image-portrait.jpg">
<source media="(min-width: 601px)" srcset="image-landscape.jpg">
<img src="image-landscape.jpg" alt="Description">
</picture>Mobile users see the portrait crop. Desktop users see the landscape. The compositions differ to serve each context optimally.
Picture can combine art direction with resolution switching:
<picture>
<source media="(max-width: 600px)"
srcset="portrait-1x.jpg 1x, portrait-2x.jpg 2x">
<source media="(min-width: 601px)"
srcset="landscape-1x.jpg 1x, landscape-2x.jpg 2x">
<img src="landscape-1x.jpg" alt="Description">
</picture>Each source has its own srcset for resolution variants. The system handles both composition and resolution adaptation.
SVG for Resolution Independence
Vector graphics don’t have resolution.
An SVG scales infinitely without quality loss. The same file renders perfectly at any size on any display. No 1x/2x/3x variants needed.
Icons are ideal SVG candidates. Simple shapes, flat colors, geometric forms. The file sizes are often smaller than bitmap alternatives while providing resolution independence.
Logos should usually be SVG. They need to appear at multiple sizes across the site, always crisp, always consistent.
Illustrations with clean lines and limited colors work well as SVG. Complex illustrations with gradients and textures may not.
SVG limitations exist. Photographs can’t be SVG. Detailed illustrations may produce larger files than optimized bitmaps. Very complex SVGs can be slow to render.
Decision framework: if the image is geometric, simple, and needs multiple sizes, SVG is probably right. If it’s photographic or highly detailed, bitmap formats work better.
Modern Image Formats
WebP provides better compression than JPEG and PNG.
Typical savings run 25-30% smaller file sizes at equivalent quality. For sites with many images, this bandwidth reduction is notable.
AVIF provides even better compression than WebP. It’s newer with less browser support but offers superior efficiency for supported browsers.
Format negotiation serves the best format each browser supports:
<picture>
<source type="image/avif" srcset="image.avif">
<source type="image/webp" srcset="image.webp">
<img src="image.jpg" alt="Description">
</picture>Browsers that support AVIF get AVIF. Browsers that support WebP but not AVIF get WebP. Older browsers get JPEG. Everyone gets an image. Everyone gets the best format they can handle.
CDNs (Content Delivery Networks) and image services can automate format negotiation. Upload one source image. The service generates and serves optimal formats automatically based on the requesting browser.
Lazy Loading
Images below the fold don’t need to load immediately.
Loading=”lazy” defers off-screen image loading:
<img src="image.jpg" loading="lazy" alt="Description">Images load as users scroll toward them. Initial page load is faster. Bandwidth for never-viewed images is saved.
Above-fold images should not be lazy-loaded. The hero image that users see immediately should load immediately. Lazy loading critical images creates visible delay.
Intersection Observer provides more control for custom lazy loading implementations. JavaScript detects when images approach the viewport and triggers loading.
Placeholder strategies improve perceived performance. Low-quality image placeholders, blur-up effects, or solid color backgrounds occupy space while full images load.
Automation and Workflow
Manual creation of multiple resolution variants doesn’t scale.
Build tools can automate image processing. Webpack, Gulp, or similar tools can take source images and generate all required variants, formats, and sizes.
Image CDNs handle everything dynamically. Upload one high-resolution source. Request any size, format, or quality through URL parameters. The CDN generates and caches variants on demand.
CMS integration varies. Some CMS platforms auto-generate responsive variants. Others require manual upload of each size. Evaluate CMS capability before committing to a responsive image strategy.
Source image quality matters. Start with the highest resolution you need (3x for the largest display size) and generate smaller variants from it. Starting with low-resolution sources limits what you can produce.
Resolution Tradeoffs
Every image variant is a tradeoff.
Higher resolution means larger files. Larger files mean slower loads. Slower loads hurt user experience and SEO.
Maximum resolution isn’t the target. It’s appropriate resolution. Images don’t need 4x variants if they don’t appear on 4x displays. Images don’t need 3x if the visual difference from 2x is imperceptible.
Test on real devices. What looks different on your 5K monitor might look identical on a phone screen. Perceptible quality differences justify additional resolution. Imperceptible differences waste bandwidth.
Performance budgets constrain image weight. If your performance budget allows 200KB of images above the fold, that constrains how many images and what resolutions fit. Design within constraints.
FAQ
Do we really need 3x images? Isn’t 2x enough?
For most images, 2x provides sufficient quality on current devices. The difference between 2x and 3x is often imperceptible, especially at smaller display sizes. For critical images like product photos or hero images where quality differentiation matters, 3x may justify the bandwidth cost. For most UI elements, 2x suffices.
Our images look fine on desktop but blurry on phones. What’s wrong?
You’re probably serving the same image to both. Phones often have higher device pixel ratios than desktop monitors. A 2x phone display showing a 1x image will blur. Implement srcset with appropriate resolution variants so phones receive higher-resolution images.
Image CDNs seem expensive. Can we handle this without them?
Yes, through build-time generation. Create all variants during your build process and serve them statically. This requires more storage but avoids ongoing CDN costs. The trade-off is less flexibility since you can’t generate new variants on demand. For smaller sites with stable image needs, build-time generation works well.
Users upload low-resolution images. Options? We can’t control their resolution.
Accept high-resolution uploads and process them into required variants. Set minimum resolution requirements where quality matters. For cases where users upload low-resolution images, either accept the quality limitation or reject uploads that don’t meet standards.
Sources
MDN Web Docs. Responsive Images. developer.mozilla.org/en-US/docs/Learn/HTML/Multimediaandembedding/Responsive_images
Web.dev. Serve Responsive Images. web.dev/serve-responsive-images
Smashing Magazine. Responsive Images Done Right. smashingmagazine.com/2014/05/responsive-images-done-right-guide-picture-srcset
CSS-Tricks. A Guide to the Responsive Images Syntax. css-tricks.com/a-guide-to-the-responsive-images-syntax-in-html
Google Developers. Image Optimization. developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/image-optimization