Art direction: why the same hero image never works on mobile and desktop

A hero image built for a 1,600px-wide screen usually places a person or product in one third of the width, with the headline and CTA filling the rest. Shrunk as-is for a 375px screen, that composition falls apart: either the subject becomes tiny and unreadable, or you crop to the center and lose the exact negative space the text was living in. The instinct to say "we'll just resize it, next/image or srcset handles the rest" solves a weight and resolution problem — not a composition problem. What has to change about the composition from one screen to another, in responsive design, has a precise name: art direction.

Resizing isn't cropping

The srcset and sizes attributes, covered in our article on image optimization, offer several resolutions of the same photo, with the same framing: the browser picks the one matching the display width and pixel density, so it never downloads a 1,920px-wide file on a phone that will only show 400px of it. That's a weight problem. Art direction addresses a different one: the photo itself needs to change — a tighter crop, a recentered subject, sometimes an entirely different image — because the composition that works next to a two-column text block stops working once that text stacks above or below the image on mobile.

The native tool: the <picture> element

HTML ships an element built exactly for this. Unlike srcset on a plain <img>, where the browser chooses based on file size, the <picture> element lets you condition the choice on an explicit media query:

• <source media="(min-width: 768px)" srcset="hero-desktop.webp"> — the wide crop, used from tablet upward.
• <source media="(max-width: 767px)" srcset="hero-mobile.webp"> — a distinct, recentered crop.
• <img src="hero-desktop.jpg" alt="…"> as the last child, as a fallback for browsers that ignore <picture> and to carry the alt text.

Here's the part that's easy to miss: the browser's preload scanner evaluates the media conditions before starting any download. Only one of the two images ever hits the network — never both.

The mistake that doubles a page's weight

The most common stand-in for <picture>, on a landing page built with Tailwind, looks like this:

• <img className="hidden md:block" src="hero-desktop.jpg" />
• <img className="md:hidden" src="hero-mobile.jpg" />

It renders correctly on screen, so it sails through visual review without anyone noticing anything wrong. The problem is invisible to the eye and entirely real on the network: display: none hides the element after render, but the src attribute fires the request before the CSS is even applied. The browser downloads both images, on mobile and on desktop alike, and only shows one. It's exactly the kind of invisible cause we cover in our article on LCP: a hero image twice as heavy as it needs to be, downloaded for nothing.

Next.js and next/image: where the automation stops

The next/image component excels on the resolution/weight axis: it automatically generates a srcset of the same image at several sizes and picks the best format (WebP, AVIF) for the browser. What it does not generate is a <picture> with several sources gated by media query — that isn't its job, and there's no official prop for it. For real art direction under Next.js, two approaches hold up: hand-write the <picture> tag with files you've already optimized (exported once as WebP/AVIF at both crops, via a build script or straight from your design tool), passing unoptimized to any fallback <Image>; or, for a purely decorative visual with no standalone informational value, a CSS background using image-set() with media queries, which gets the same conditional-loading behavior as <picture>.

The link to a mobile visitor's data budget

This isn't only a PageSpeed-score concern. A study published in Information Systems Research, by Xiaopeng Luo, Cheng He, Yu Jeffrey Hu, Xitong Li, and Yuan Cheng, looking at bookings on a hotel app, found that visitors on mobile data show roughly twice the price sensitivity of those on Wi-Fi, an effect attributed to the perceived cost of data usage (Luo et al., Information Systems Research). A hero image that's twice as heavy as it needs to be, as in the mistake above, doesn't just slow down the render — it adds to the visitor's data plan at the exact moment you're asking them to reach for their card. Art direction, by serving a genuinely lighter crop on mobile rather than a merely shrunk one, works on that perceived cost as much as it does on LCP.

Don't lose the message in the crop

Cropping tighter to save weight has a downside: the risk of cutting exactly the element meant to persuade. Jan Panero Benway showed, in a study that remains a reference on online visual attention, that visitors miss elements that are visually prominent when they're focused on another task — the effect she named "banner blindness" (Benway, 1998). A mobile crop that shrinks or pushes down the headline to make room for the subject of the photo makes that risk worse, not better. The most reliable fix: keep the headline and CTA as real HTML, overlaid on the image rather than baked into it, so cropping the photo never touches the text carrying the message.

Which images deserve it — and which don't

Art direction has a cost: two exports to produce and maintain instead of one, two files to update on every visual refresh. It earns its place on the hero image of the first screen, when the desktop composition genuinely places the subject off-center — a person to one side, a product shifted to leave room for text. It almost never earns its place on content images further down the page (client logos, screenshots, testimonial photos): there, a plain srcset resize is enough, because the original composition stays legible at any width.

A 4-step method

1. Find the images whose desktop composition is off-center (subject shifted, text overlaid) rather than centered — those are the only legitimate candidates for art direction.
2. Ask your designer for two separate exports (or crop them yourself): a wide frame for desktop/tablet, a tighter, recentered frame for mobile, each in WebP and AVIF.
3. Implement with <picture> and <source media>, or with a CSS image-set() background for a purely decorative visual — never with two <img> tags simply hidden by CSS.
4. Check the network tab in your browser's dev tools, emulating a mobile device, to confirm only one of the two images actually hits the network — not both.

All ten LanderKit templates already ship this pattern on their hero sections — the tighter mobile crop on the Single-product E-commerce template (demo) is a good example, as is the recentered photo on the Coach & Consultant template. A solid base to start from rather than retrofitting art direction onto an existing design.