Responsive images in production

Responsive images are a content-delivery system rather than a single markup feature. The browser needs suitable source files, accurate layout information and a reliable fallback; the publishing platform needs to generate and retain those assets without asking editors to make rendering decisions.

Separate resolution switching from art direction

Use srcset when each candidate contains the same composition at a different intrinsic width. Add a sizes value that describes the image’s rendered width at the layout breakpoints. The browser can then select an appropriate candidate using viewport size, device pixel ratio and its own resource logic.

Use <picture> when the composition must change—for example, a wide scene on desktop and a tighter crop on a narrow screen. Art direction is an editorial decision and should remain limited to components where the subject would otherwise become illegible. Generating arbitrary crops for every upload consumes storage without improving the page.

<img
  src="project-800.jpg"
  srcset="project-480.jpg 480w,
          project-800.jpg 800w,
          project-1280.jpg 1280w"
  sizes="(min-width: 64em) 50vw,
         (min-width: 40em) 75vw,
         100vw"
  alt="Completed service counter">

Write sizes from the layout

The sizes attribute describes the rendered slot, not the available image files. Measure the component at each breakpoint and express that relationship. A card occupying one third of a desktop grid may still use the full viewport width on a phone. Declaring 100vw everywhere causes high-density displays to select needlessly large sources.

Review sizes whenever the grid changes. Keep the rule close to the component implementation and include it in visual regression tests. If a content image appears in multiple components, each rendering context may need different markup even though the source asset is shared.

Build an intentional candidate set

Choose widths from observed component sizes, not a uniform sequence of every hundred pixels. Candidates should be close enough to avoid large over-delivery but far enough apart to justify another derivative, cache entry and storage object. Preserve the original upload outside the public delivery path so future formats and crops can be regenerated.

Apply orientation, colour-profile and metadata handling consistently. Set a quality target per format and content class: screenshots, illustrations and photographs respond differently to compression. Inspect visible output as well as byte size, particularly around text, gradients and high-contrast edges.

Introduce newer formats with a fallback

In 2018 WebP can reduce transfer size for supported browsers, but support remains uneven and it must not be the sole source. A <picture> source can offer WebP first while the nested image supplies JPEG or PNG. Detect capability through markup rather than user-agent parsing, and ensure CDN cache keys do not mix negotiated formats.

<picture>
  <source type="image/webp"
          srcset="project-480.webp 480w,
                  project-960.webp 960w">
  <img src="project-960.jpg"
       srcset="project-480.jpg 480w,
               project-960.jpg 960w"
       alt="Project team workshop">
</picture>

Protect layout and accessibility

Retain known image dimensions in the content model and reserve the correct aspect ratio before the resource finishes. Responsive CSS can scale the image while a wrapper or calculated placeholder preserves its space. This prevents surrounding text and controls moving during download on slower connections.

Alternative text describes the purpose of the image in context; it is not a filename or a list of visible objects. Decorative images should use an empty alternative. When art-directed crops are used, confirm that every crop retains the subject needed to support the same description.

Delay offscreen images with care

Native image lazy loading is not yet a dependable cross-browser production feature. If offscreen loading materially improves the page, use progressive enhancement around Intersection Observer with a small fallback. Keep initial-view images in normal markup and test without JavaScript so essential content is never dependent on the observer.

Do not delay every image. A large hero discovered only after script execution will start later than an ordinary image in the parser stream. Measure the complete loading sequence on a constrained mobile connection before accepting a lower initial request count as an improvement.

Test delivery, not just markup validity

Use browser developer tools to inspect the selected current source at representative viewport widths and pixel densities. Confirm transfer sizes with a cold cache, then resize or reload according to the behaviour being tested. Browsers may retain a larger candidate already downloaded, which can conceal selection errors during an informal resize test.

Track image bytes by template in performance monitoring. Sample real editorial content, including panoramic uploads, small legacy assets, transparent logos and images without metadata. Responsive image markup is successful when it consistently delivers an adequate source without making content editors understand candidate selection.