Implementing Responsive Imagesfor Drupal 11 , 10 , 9 , and 8

Home » Performance Optimization » Implementing Responsive Images
Last updated :  
11.x , 10.x , 9.x , 8.x

A phone with a 375px-wide screen has no use for the same 1600px-wide hero image a desktop monitor needs — downloading it anyway wastes bandwidth and slows the page for exactly the visitors most likely to be on a constrained mobile connection. Responsive images fix this properly: the browser picks the right size for its actual viewport, before downloading anything, not after.

What you'll learn in this lesson

  • How core's Responsive Image module maps breakpoints to image styles
  • The real mechanism: srcset and sizes, not JavaScript
  • Why the browser — not your server — makes the final size decision

A responsive image style definition

# config/install/responsive_image.styles.example_responsive.yml
id: example_responsive
label: 'Example responsive'
breakpoint_group: responsive_image
fallback_image_style: article_thumbnail
image_style_mappings:
  - image_mapping_type: image_style
    image_mapping: article_thumbnail_small
    breakpoint_id: responsive_image.viewport_sizing.xs
    multiplier: 1x
  - image_mapping_type: image_style
    image_mapping: article_thumbnail_large
    breakpoint_id: responsive_image.viewport_sizing.lg
    multiplier: 1x

This maps different existing image styles (each already defined the way you saw two lessons ago) to different breakpoints — small viewports get the small style, large viewports get the large one, all driven by configuration, no custom template logic required.

What actually gets rendered

<img srcset="/styles/small/image.jpg 480w, /styles/large/image.jpg 1200w"
     sizes="(max-width: 600px) 480px, 1200px"
     src="/styles/large/image.jpg"
     alt="...">
The browser decides, not JavaScript, not the server. srcset lists candidate images with their real widths; sizes tells the browser how the image will actually be displayed at different viewport widths. The browser combines both, plus its own knowledge of the device's screen density and current viewport, to pick exactly one image to download — before any CSS has even necessarily finished loading. No JavaScript runs, no server-side device detection happens; this is native HTML/browser behavior.

Why this beats a fixed "mobile" and "desktop" size

A hand-rolled "just serve a smaller image on mobile" approach usually means picking two or three fixed breakpoints and hoping they cover real-world device diversity well enough. srcset/sizes lets the browser make a genuinely informed choice from as many candidate sizes as you define, accounting for the actual device's pixel density (a "1x" vs "2x" retina screen) as part of its decision — something a fixed two-tier system can't express at all.

Quick check: does the server decide which image size to send, or does the browser? If you said the browser — the server offers candidates via srcset, and the browser's own viewport/density knowledge picks which one to actually request — you've understood the core mechanism this lesson is built on.

Key takeaways

  • Responsive Image maps breakpoints to existing image styles through configuration, no custom template logic.
  • The real mechanism is native srcset/sizes HTML attributes — no JavaScript, no server-side device detection.
  • The browser picks the actual image to download, accounting for both viewport width and screen pixel density.
  • This beats fixed mobile/desktop breakpoints by letting the browser choose from many candidates instead of two.

Coming up next

You've now covered sizing, compression, format, and responsive delivery. Last in this section: making sure all these generated derivatives themselves get cached correctly rather than regenerated repeatedly.