Responsive Images: Serving the Right Size to Every Screen

Quick answer: Responsive images mean the browser picks a file that matches the layout width and screen density instead of always downloading one huge photo. Use srcset and sizes for most content images, and the picture element when you need art direction or format fallbacks. Compress well, prefer modern formats where supported, and lazy-load below-the-fold images so first paint stays fast.

Why one oversized JPG hurts

Designers export a 2000px wide hero because it looks sharp on a large monitor. A phone may display that hero at 360px CSS width. Without responsive images, the phone still downloads the 2000px file, burns data and delays Largest Contentful Paint. Core Web Vitals (LCP, FID, CLS) were announced in May 2020, with a page experience update planned for 2021. Right-sized images help LCP and users today, ranking change or not.

Responsive images also reduce layout surprises when you declare width and height (or aspect-ratio boxes) so space is reserved before the file arrives.

For WordPress sites, start with sane defaults for thumbnails and full sizes. Our guide to WordPress image sizes pairs well with this article. Broader speed work sits in WordPress speed optimization and mobile page speed.

The two problems: resolution switching and art direction

Resolution switching is the common case. Same crop, different file dimensions (and sometimes density). The browser chooses from a list based on layout width and device pixel ratio.

Art direction is when the crop itself should change. A wide desktop hero may need a tighter square crop on mobile so faces stay in frame. That needs the picture element with multiple source blocks, not only srcset on one img.

Know which problem you are solving before you write markup.

srcset and sizes in plain terms

A typical content image:

<img
  src="/images/team-800.jpg"
  srcset="/images/team-400.jpg 400w,
          /images/team-800.jpg 800w,
          /images/team-1200.jpg 1200w,
          /images/team-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1000px) 50vw,
         600px"
  width="800"
  height="500"
  alt="The operations team reviewing a project board">

• src: fallback for older clients and a default if srcset is ignored
• srcset with w descriptors: list of files and their true pixel widths
• sizes: how wide the image will be in the layout at different viewport widths (CSS pixel widths, not device pixels)
• width and height: help the browser reserve space and limit CLS

If sizes is wrong, the browser picks the wrong candidate. A common mistake is leaving sizes at the default 100vw while the image only ever renders at half the column width. That wastes bandwidth on mobile and desktop.

Density descriptors (1x, 2x) still work for fixed-width icons. For fluid layouts, width descriptors (w) plus sizes are usually clearer.

When to use picture

Use picture when:

• You change crop or focal point by breakpoint
• You serve WebP (or another format) with a JPG/PNG fallback
• You ship a dark-mode or theme-specific asset set

Example pattern for format plus fallback:

<picture>
  <source type="image/webp" srcset="/images/hero-800.webp 800w,
                                    /images/hero-1600.webp 1600w"
          sizes="100vw">
  <img src="/images/hero-800.jpg"
       srcset="/images/hero-800.jpg 800w,
               /images/hero-1600.jpg 1600w"
       sizes="100vw"
       width="1600"
       height="900"
       alt="Warehouse aisle with packed orders ready to ship">
</picture>

As of September 2020, WebP is supported in Chrome, Firefox and Edge. Safari 14 added WebP support around this same month, so fallback JPGs still matter for users on older Safari. AVIF is not yet a mainstream choice for most production sites. For a deeper format discussion, see WebP images.

Lazy loading without breaking LCP

Native lazy loading with loading="lazy" shipped in Chrome 76 (2019). WordPress 5.5 (August 2020) adds it by default on many images. Rules of thumb:

• Do lazy-load below-the-fold galleries, product grids and secondary content images
• Do not lazy-load the LCP candidate (usually the main hero or primary product image)
• Keep width and height (or aspect ratio) so lazy images do not shove the layout when they appear
• Older browsers ignore the attribute; that is fine

Script-based lazy loaders still exist. Prefer native when you can, and avoid stacking three lazy libraries on one theme. More detail lives in lazy loading images.

Compression and generation workflow

Responsive markup cannot fix a poorly compressed master file.

1. Start from a high-quality master, then export the widths you actually need
2. Strip useless metadata when it does not carry licensing you must keep
3. Use sensible quality settings; visually check faces and text in the image
4. Generate WebP alongside JPG/PNG when your toolchain supports it
5. Give editors a maximum upload width so the media library does not fill with 5000px phone photos

On WordPress, combine core resized sizes with a disciplined media workflow. WordPress image optimization covers compression habits that still apply when you add srcset.

CDNs and image transformation services can resize on the fly. They help when traffic and catalog size justify them. For smaller sites, pre-generating a handful of widths is enough and easier to reason about offline.

CMS and WordPress specifics

Modern WordPress outputs srcset and sizes for many attachments automatically when you use core image functions and the block editor. You still need to:

• Register image sizes that match real theme breakpoints
• Avoid CSS that displays a thumbnail at full column width (blurry upscales)
• Replace hard-coded full-size URLs in custom templates with functions that emit responsive markup
• Check page builders that insert fixed full-size images without srcset
• Confirm featured images used as heroes are not lazy-loaded if they are the LCP element

Custom themes should treat image helpers as part of the design system, not as an afterthought in each template.

Testing checklist

Before you call the work done:

1. Resize the browser from phone to desktop and watch which file Network picks
2. Throttle to a slow 3G profile and compare hero weight before and after
3. Confirm sizes matches computed layout width in DevTools
4. Verify WebP is served where supported and JPG/PNG where not
5. Check that the LCP image is not lazy-loaded
6. Look for layout shift when images load; add dimensions if the page jumps
7. Spot-check a product grid and a long article on a real phone

Automated lab tools help, but a Network panel pass on a mid-range device catches many sizes mistakes faster than another round of theory.

Common mistakes

Shipping only a 2x desktop asset. Sharp on a phone retina screen still means too many kilobytes if the layout width is small. Offer smaller w candidates.

Ignoring sizes. Without it, the browser assumes 100vw and often over-downloads.

Art-directing with CSS crop alone. Cropping a huge image with CSS still downloads the huge image. Change the file when the crop matters.

Lazy-loading the hero. Saves nothing important and can delay LCP.

Using GIFs for long product clips. Prefer compressed video for anything beyond a tiny decorative loop.

Forgetting SVG for simple icons. Icons and logos often belong as SVG, not as a stack of PNG densities.

FAQ

Do responsive images replace compression?

No. They choose among candidates. Each candidate still needs proper compression and format choice.

Is picture required for every image?

No. Most content images only need srcset and sizes on img. Use picture for art direction or format switching.

Will Safari users without WebP break?

Not if you keep a JPG or PNG img fallback inside picture or as the default src. New Safari releases are adding WebP; older ones still need the fallback.

How many widths should we generate?

Enough to cover your real layout breakpoints and common densities without filling disk with near-duplicates. Many sites do well with three to five widths per photo plus a tiny thumbnail.

Ship the right pixels

Responsive images are a layout contract: tell the browser how wide the image will be, give it honest candidates, and keep heroes eager while the rest can wait. Add WebP with fallbacks where your audience benefits, and keep compression in the editorial workflow. When you want help tightening templates and media performance on a business site, see Turn visitors into customers.