Art Direction With picture: Crops and Bytes Measured on 3 Screens

A wide landscape photo shrinks to a thin strip on a phone, and the subject becomes too small to read. The <picture> element lets you send a different crop to narrow screens. Does that tighter crop cost extra bytes, and does it actually change what a phone reader sees? We built the same article twice, once with one landscape image and once with a portrait crop for phones, and loaded both on three screen sizes.

The two versions

The photo is a CC0 street scene of a fruit and vegetable market whose subject is the red sign above the entrance (Sang Farsh Fruit and Vegetable Market by Behnam9395, via Wikimedia Commons).

• Single image: a 16:9 crop in four widths (480 to 1600 pixels, WebP quality 75) with srcset and a correct sizes value.
• picture with art direction: the same landscape set as the default, plus a <source media="(max-width: 600px)"> pointing to a 4:5 portrait crop in three widths (480, 768 and 1080 pixels) centred on the sign and the street below it.

What did not work first: we first let libvips choose the portrait crop automatically with its “attention” strategy, which looks for the most detailed region. It picked the sky. The crop you see below was set by hand to keep the sign in the frame. Automatic cropping is a starting point, not a substitute for looking at the result.

Both pages were loaded three times each in Chrome 154 on a phone (390 × 844 at 3× density), a tablet (768 × 1024 at 2×) and a desktop (1440 × 900 at 1×), and we recorded which file was downloaded. See the methodology for the full conditions.

Results

On the phone, the portrait crop was slightly lighter, not heavier. Chrome downloaded the 1080-pixel portrait file (51 KB) instead of the 1600-pixel landscape file (53 KB) that the single-image version needed for a 3× screen. The sign’s lettering is readable in the portrait version; in the landscape version the whole photo is 201 CSS pixels tall, about a quarter of the screen, and the sign is a thin band inside it.

On the tablet and the desktop, nothing changed. Both versions downloaded the same landscape files (53 KB on the tablet, 22 KB on the desktop), because the portrait source only applies below 601 pixels. Art direction added no bytes where it was not used.

The markup that was tested

<picture>
  <source media="(max-width: 600px)"
          srcset="market-portrait-480.webp 480w,
                  market-portrait-768.webp 768w,
                  market-portrait-1080.webp 1080w"
          sizes="calc(100vw - 32px)"
          width="1080" height="1350">
  <img src="market-1024.webp"
       srcset="market-480.webp 480w, market-768.webp 768w,
               market-1024.webp 1024w, market-1600.webp 1600w"
       sizes="(max-width: 792px) calc(100vw - 32px), 760px"
       width="1024" height="576"
       alt="Fruit and vegetable market">
</picture>

Two details matter. The width and height on the <source> give the portrait crop its own aspect ratio, so the browser reserves the right space before the image arrives (our layout shift test shows why that matters). The <img> keeps one alt text for both crops, because both show the same subject.

When art direction is worth it

• When the subject of a wide image becomes too small on phones: signs, faces in group photos, products in a scene, charts with labels.
• When the two crops still show the same content. If the phone version would tell a different story, it needs its own alt text and probably its own image.
• Not for every photo: each crop is another set of files to produce and check. For purely decorative images, a single responsive image is enough.

Practical conclusion

• In our test, a portrait crop for phones made the subject readable at no extra cost (51 KB instead of 53 KB) and changed nothing on larger screens.
• Choose the crop by eye. The automatic “attention” crop picked the wrong region for this photo.
• Put width and height on each <source> with a different aspect ratio.

How this connects to our other tests

Art direction combines two techniques the lab measured separately. The srcset inside each <source> still decides the file width, as in our srcset test, and the phone downloaded a 1080-pixel portrait file for the same reason it downloads large files elsewhere: a 3× screen. The width and height on each source do the layout work that our layout shift test measured, and if the art-directed image is the first thing on the page, the advice from our lazy-loading test applies: do not lazy-load it.

Repeat this test on your own images

To test art direction on your own page, export the two crops, add the <picture> markup above with your file names, and check it at three widths in DevTools device emulation: a phone, a tablet and a desktop. In each case select the image and read $0.currentSrc to confirm which crop was chosen, and look at the Network panel’s Transferred column for the bytes. Two mistakes are easy to make. A media condition that overlaps your layout’s breakpoints can serve the portrait crop into a wide column; set it to the width where the landscape image becomes too small, not to a generic phone width. And forgetting width and height on the <source> makes the page jump when the portrait image arrives. Our script build_pages.mjs contains both test pages, and run_loading.mjs the three-device check.

Limitations

One photo, one breakpoint and one browser. The byte result depends on how much the crop removes; a tighter crop of a busy image can be lighter or heavier than in our case.

Data and files

Download loading-artdir.csv (6 rows, 0.9 KB) · Method: testing methodology. Photo: image credits.