Art Direction with the Picture Element

Responsive images usually mean one image at several sizes: the browser picks the smallest file that fills the slot at the device's pixel density. That works until the image's composition stops working at a different shape. A 16:9 desktop hero showing a product and a person at a whiteboard becomes, scaled down to a phone's width, a strip in which neither is recognisable. The fix is art direction — a different crop for narrow viewports — and the <picture> element with media conditions is how HTML expresses it.

This guide implements art-directed hero images on a static marketing site in Astro, Eleventy and Hugo: generating the crops at build time, writing <picture> markup with per-source dimensions so nothing shifts, preloading the right variant for the LCP, and measuring the result. It is part of Image Optimization Pipelines in Astro, and builds on Reducing LCP from Hero Images on Static Sites.

Prerequisites

• Source images with enough resolution to crop (the landing pages here used 3,000-pixel-wide originals).
• A decision on breakpoints where the composition changes — typically one, sometimes two.
• An image pipeline in the generator: astro:assets, @11ty/eleventy-img, or Hugo image processing.

When Resizing Is Not Enough

The marketing site's landing pages had 16:9 hero photographs. On phones, at 390 CSS pixels wide, the hero was 219 pixels tall, and the product in the photo was 40 pixels across. Design wanted a 4:5 portrait crop centred on the product for narrow screens, and the original wide composition from 768 pixels up. That is a change of content and aspect ratio, not resolution — exactly what srcset cannot express, because srcset candidates are interchangeable hints the browser may choose between, while <picture> sources with media are mandatory choices.

Generating Crops at Build Time

Crops can be separate source files prepared by a designer, or generated from one original with a focal point. Generating them keeps one source of truth. A focal point stored in frontmatter (heroFocus: [0.62, 0.48] as fractions of width and height) tells the pipeline where to centre each crop.

Astro — getImage with explicit dimensions and fit/position, called once per crop:

---
import { getImage } from 'astro:assets';
import hero from '../assets/hero-whiteboard.jpg';
const wide = await Promise.all([960, 1440, 1920].map((w) => getImage({ src: hero, width: w, height: Math.round(w * 9 / 16), fit: 'cover', format: 'avif' })));
const tall = await Promise.all([390, 780, 1170].map((w) => getImage({ src: hero, width: w, height: Math.round(w * 5 / 4), fit: 'cover', position: '62% 48%', format: 'avif' })));
const srcset = (imgs) => imgs.map((i) => `${i.src} ${i.attributes.width}w`).join(', ');
---

Eleventy — eleventy-img does not crop, so crop first with sharp and pass the buffer:

const crop = await sharp(src).extract(focalCrop(meta, 4 / 5, focus)).toBuffer();
const tall = await Image(crop, { widths: [390, 780, 1170], formats: ['avif', 'webp', 'jpeg'], outputDir: '_site/img/' });

Hugo — .Crop with an anchor, or .Fill with Smart cropping, per variant:

{{ $tall := $img.Fill "1170x1463 Center avif q60" }}
{{ $wide := $img.Fill "1920x1080 Center avif q60" }}

Hugo's Smart anchor chooses the crop by image content, which worked well for photographs of products but occasionally cut faces; an explicit anchor per image in frontmatter was more predictable.

The Picture Markup

Order matters: the browser takes the first <source> whose media and type match. Put the most specific media condition first, formats from newest to oldest within each composition, and a fallback <img> last:

<picture>
  <source media="(min-width: 48em)" type="image/avif"
          srcset="/img/hero-wide-960.avif 960w, /img/hero-wide-1440.avif 1440w, /img/hero-wide-1920.avif 1920w"
          sizes="100vw" width="1920" height="1080">
  <source media="(min-width: 48em)" type="image/webp" srcset="…" sizes="100vw" width="1920" height="1080">
  <source type="image/avif" srcset="/img/hero-tall-390.avif 390w, /img/hero-tall-780.avif 780w, /img/hero-tall-1170.avif 1170w"
          sizes="100vw" width="1170" height="1463">
  <img src="/img/hero-tall-780.jpg" srcset="…" sizes="100vw" width="1170" height="1463"
       alt="Product manager sketching the release plan on a whiteboard next to the dashboard"
       fetchpriority="high" decoding="async">
</picture>

The width and height attributes on each <source> are what prevent layout shift: browsers use the dimensions of the selected source to compute the aspect ratio before the image loads. Without them, the browser uses the <img> attributes for every source, reserving a 4:5 box on desktop that then collapses to 16:9 when the image arrives — a shift of about 0.2 on the wide layout in testing. Per-source dimensions are supported in all current browsers.

Preloading the Right Variant

The hero is the LCP element, so it gets fetchpriority="high". On this site the <picture> was in the initial HTML and discovered early, so a preload was not needed. When the hero is referenced from CSS or discovered late, preload each composition with a media condition that matches its source exactly, so each viewport preloads only its own variant:

<link rel="preload" as="image" media="(min-width: 48em)" type="image/avif"
      imagesrcset="/img/hero-wide-960.avif 960w, /img/hero-wide-1440.avif 1440w, /img/hero-wide-1920.avif 1920w" imagesizes="100vw">
<link rel="preload" as="image" media="(max-width: 47.99em)" type="image/avif"
      imagesrcset="/img/hero-tall-390.avif 390w, /img/hero-tall-780.avif 780w, /img/hero-tall-1170.avif 1170w" imagesizes="100vw">

Mismatched media conditions are the classic mistake: a preload for (min-width: 768px) with a source for (min-width: 48em) behaves identically at default font size but not when the reader has changed their default font size, and then the browser downloads both variants.

Making It Editable

Art direction only works long term if editors can use it without a developer. The content model on this site gives each hero image an optional focal point and an optional separate mobile image. Most heroes need only the focal point: the pipeline generates both crops from the one upload, and a preview page shows the wide and tall crops side by side so the editor can nudge the focal point before publishing. A separate mobile image is for the rare case where no crop of the original works, such as a wide chart that must be redrawn vertically. A build check warns when a hero has neither a focal point nor a mobile image, since the default centre crop is right only about two thirds of the time.

Measured Impact

Two landing pages, before (one 16:9 image scaled with srcset) and after (art-directed <picture>), field data from RUM and Lighthouse lab runs:

Art direction is not free: the mobile crop covers more of the screen, so it is more pixels and more bytes, and LCP rose by about 100 ms. The design team judged the trade worth it, and the A/B test agreed. Keeping quality at AVIF q55 for the tall crop limited the cost; the image looked identical to q65 at phone sizes in a side-by-side review.

Pitfalls & Rollback

• Missing per-source dimensions. The browser reserves the fallback's aspect ratio for every source and shifts when a different one loads.
• Using srcset for different crops. The browser may pick any candidate; use media for mandatory changes.
• Mismatched preload media conditions. Both variants download; copy the exact conditions.
• Cropping out the alt text's subject. Alt text describes the image; make sure each crop still shows what it says, or vary the alt per crop in the content model.
• Rollback: the component that renders the hero can fall back to a single <img> with srcset; the extra crops remain in the build output but are unused.

Conclusion

When a hero's composition does not survive being scaled down, give narrow viewports their own crop with <picture> and media, generate the crops from one original with a focal point at build time, and put width and height on every source so nothing shifts. Preload per composition only when the image is discovered late. The mobile hero on this site became recognisable again, at a small and deliberate cost in bytes.

FAQ

What is art direction in responsive images?

Serving a differently cropped or composed image depending on the viewport, not just a smaller version of the same image. A wide desktop hero might become a tighter portrait crop on mobile so the subject stays visible, which srcset alone cannot do.

When should I use picture with media instead of srcset and sizes?

Use srcset and sizes when every candidate is the same image at different resolutions and the browser may choose freely. Use picture with media conditions when the content or aspect ratio of the image must change at specific breakpoints, because media conditions are mandatory while srcset choices are hints.

How do I avoid layout shift when the aspect ratio changes by breakpoint?

Give each source its own width and height attributes, which browsers use to compute the aspect ratio for the selected source, or set aspect-ratio in CSS per breakpoint. Both reserve the correct space before the image loads.

Can I preload an art-directed LCP image?

Yes, with one preload link per source using the media attribute and imagesrcset, so each viewport preloads only the variant it will use. Media conditions on the preloads must match the picture sources exactly.

Related

• Parent: Image Optimization Pipelines in Astro — the full image pipeline.
• Responsive Images with srcset in Eleventy — resolution switching.
• Serving AVIF with Fallbacks on Static Sites — format sources inside picture.
• Fixing LCP When the Hero Is a Background Image — when the hero is in CSS.
• Reserving Space for Images and Embeds to Stop Layout Shift — dimensions and aspect ratio.