Art-Directed Hero and Banner Systems on Shopify

Definition

Heroes, slideshows and banners built with genuinely separate desktop and mobile artwork rather than one image reflowed: a source chosen at a breakpoint, hand-written srcset ladders, aspect ratios computed in Liquid from the uploaded assets so the box is reserved before decode, per-slide typography emitted as scoped custom properties, art-directed video backgrounds, and first-slide loading priority derived from section position rather than a checkbox.

The Evidence

• Evidence strength: 34 live, Deploi-attributed builds across 3 Shopify storefronts.
• Split by storefront: Nudestix 15, LUS Brands 11, Three Ships 8.
• Split by attribution: 31 Deploi-authored, 3 modifications of vendor theme code — named as such on each build page.
• Evidence quality: thirteen carry code plus client working records. Twenty-one are documented from the code; no client-side record of the decision survives.
• Confidence: 12 strong, 22 moderate.
• Surfaces: landing pages and the homepage above everything else, then collection pages and the product page.
• Status: Live, verified 2026-09-06.

This is among the largest capabilities in the section, and the reason is mundane: the hero is where every campaign lands, so it is the component that gets rebuilt most often and diverges most between storefronts.

How It's Actually Built

Start with the platform fact, because it decides everything downstream. Shopify's image_tag filter emits one <img>, and srcset gives that image sizes. Sizes are not art direction. Art direction is a different crop — a wide band on desktop, a tall frame on mobile, shot and retouched separately — so the theme has to render two image trees and choose between them.

Two shapes of that choice show up. One renders a <picture> with a min-width: 750px <source> carrying the desktop ladder and the mobile asset as the base <img>, falling back to the desktop file when no mobile file is uploaded. The other ships two <img> elements toggled by hide-mobile / hide-desktop utility classes, which fits a theme whose layout CSS already expects a single fill image. Both hand-build the srcset ladder rather than taking a filter's default, and both guard every candidate width with an image.width >= n check.

Reserving the box is the second piece. Both breakpoints' aspect ratios are computed in Liquid from the real uploaded assets and published as CSS custom properties — --de-hero-ar-mobile and --de-hero-ar-desktop in one implementation, --mobile-ratio-percent in another, with an adapt mode that takes the asset's own ratio. That is what lets the placeholder match the image that will actually load at that breakpoint rather than the one that will not.

Loading priority is derived, not configured. section.index == 1 selects loading="eager" with fetchpriority="high"; anywhere else in the template order the same section renders itself lazy. An "is this the hero" checkbox would have made the correct behavior a setting somebody has to know about.

Typography is where the merchandiser gets in. Section settings cannot express responsive values, so per-block type specs are emitted as CSS custom properties inside a {% style %} block scoped to block.id — a desktop and a mobile value for size, line height, weight and letter spacing — and the stylesheet consumes them inside its own media queries. One markup path, both breakpoints. Copy also carries a [[highlight]] bracket convention: the delimited run is wrapped in a span colored from a --highlight-color setting, which gives an accent word without letting anyone paste markup into a heading.

Video heroes are the same problem one layer harder, because there is no <picture> equivalent for video. Two <video> elements are the only way to art-direct one, and both stay in the DOM. So sources are emitted on data-src and only promoted to src once a breakpoint resolves through matchMedia; preload="none" and a poster carry the first paint; and a matchMedia change listener pauses the video that just became inactive. Playback control is a <play-pause> custom element that reads a CSS selector from its own data-video attribute and mirrors the real play, pause and ended events, so a slide can be cloned or re-rendered by the theme editor and the button still drives the right video.

The Buy-vs-Build Position

The corpus's own verdict on this capability:

Always built — genuinely separate desktop and mobile artwork with LCP control is the requirement stock sections and hero apps consistently miss.

There is no Build-vs-Buy decision page for heroes, and that is the honest position rather than an omission: across 34 builds there is no app attempt to compare against. Hero and slideshow apps do a real job — a slide editor without a theme deploy. What they generally do not give is two genuinely different assets with a server-rendered choice between them, a ratio reserved from the asset that will load, and the first slide's priority decided by where the section sits. All three happen before or during the first paint, which is the part an app rendering after paint cannot reach.

The Builds

Twelve of the 34 have published pages. The rest — offer banners, press and community grids, the recycling-programme page, the stockist layout and the remaining campaign sections — are documented and will follow.

LUS Brands

• Variant-aware PDP hero banner driven by a 'heroic' metaobject — a metaobject supplies the art and copy per variant, and the banner refetches itself through the Section Rendering API on variant change. High complexity, product page.
• Featured-collection product card with metafield hero/hover media and a tag-driven badge stack — primary and hover media chosen per product by metafield. High complexity, home and collection.
• DE Hero: art-directed image/video hero with layout controls — hand-built <picture>, both ratios published as custom properties, priority derived from position. Medium complexity, home and landing.
• Responsive video hero with independent desktop/mobile sources and single-source-of-truth playback controls — a <video-hero> element that loads only the active breakpoint's encode. Medium complexity, home and landing.
• Per-collection hero banner driven entirely by collection metafields — one section instance serves every collection, bound through dynamic sources. Medium complexity, collection.
• Brand story split panel: one section that renders image, hosted video or YouTube with separate desktop and mobile assets — a media-type switch with a Liquid-computed mobile ratio. Medium complexity, landing.
• Marketing image banner with mobile art, typography controls and highlight headings — a fork of Dawn's image banner that keeps the vendor class contract. Medium complexity, landing and collection.

Nudestix

• Homepage hero carousel v2 - video and split-image slides with per-slide typography control — two independent carousels, because the desktop composition is a split and the mobile one is a single crop. High complexity, home.
• Hero slide content renderer with per-breakpoint typography controls — one snippet renders every slide's copy and CTA from block settings. Medium complexity, home and landing.
• Accessible play/pause web component for autoplaying hero video — resolves its own video by selector and mirrors the video's real state. Low complexity, global.

Three Ships

• Landing-page hero sections with a no-JS add-to-cart on page templates — a block-repeating hero whose CTA can carry a merchandiser-picked product without the theme's cart script. Medium complexity, landing and home.
• Skin quiz entry-point sections: separate desktop and mobile artwork in one section — the same block set rendered twice, each wrapper with its own background picker. Low complexity, landing and home.

What This Rests On

• Liquid section schema and settings — 33 of the 34 builds. Everything a merchandiser can change about a hero is a schema setting, which is why this primitive is effectively universal here.
• Theme blocks — 7 builds; the unit a slide, tile or banner actually is in the theme editor.
• Metafields — 4 builds; where the art and copy live when the hero has to serve every collection or every variant from one section instance.
• Responsive images — the hand-built srcset ladders and the width guards that keep small assets from being offered upscaled.
• Custom elements — the video hero and its playback control, self-wiring so a slide can be cloned or re-rendered.
• Section Rendering API — how a product-page hero re-renders itself when the shopper picks a different variant.
• Dynamic sources — the binding that lets a plain image picker read from a collection metafield instead.

What Varies by Storefront

Theme base sets the floor. LUS Brands runs Dawn 15.4.1, so heroes are Dawn sections rebuilt or forked with the vendor's class contract preserved. Nudestix runs Dawn 6.0.2 — nine major versions older, with no theme blocks and no per-block CSS scoping — so a section needing a full type scale per slide writes its own {% style %} block out of settings. Three Ships runs Palo Alto 5.8.0 by Presidio Creative, a paid premium theme, so its heroes are custom sections added beside vendor code rather than forks of it, and the build pages say which is which.

What the hero is for varies more than the code does. A haircare storefront needs the hero to introduce a collection, so the interesting work is metafield binding: one section instance serves every collection page and launching one is filling four fields. A shade-led cosmetics catalogue needs the homepage hero to be the campaign, so the work is per-slide art direction, and the hero splits into two carousels because the desktop composition is not the mobile one reflowed. A skincare catalogue treats heroes as page furniture — one hero section is mounted by 36 templates, and another falls back to page.title when no title is set, which is why it spread across policy, quiz and campaign pages without anyone configuring it.

Where This Gets Hard

Art direction is an asset commitment before it is a code feature. Every campaign now needs two crops, and someone has to produce both on the campaign's schedule. The systems here fall back sensibly when the second file is missing — the desktop asset serves both breakpoints — but a fallback is not the design, and a hero whose mobile slot is empty half the time is an expensive way to ship one image. Ask who is producing the second crop before you build the thing that expects it.

Video is a bigger commitment than it looks. Browsers only autoplay muted, so a hero video cannot carry sound and the story has to survive without it. prefers-reduced-motion has to actually stop it. What paints first is the poster image, so the poster is the real design decision and the video is the reward for waiting. Every one of those states — playing, paused, reduced motion, breakpoint changed mid-session — is a state somebody owns after launch.

On a premium theme the hero often starts as vendor code, and extending it is a divergence you re-check on every theme update. Where a theme ships its runtime compiled there is no source to patch and no supported hook, so the honest move is to add a section beside the vendor's rather than reach into it. That is a property of how premium themes are distributed, not a mark against any one of them.

So there are storefronts we would tell not to build this. If one crop genuinely works at both breakpoints — and for a lot of catalogues it does — the two-tree system doubles your asset cost for nothing. If the hero changes twice a year, the stock banner section already does the job. And if nobody will own hero JavaScript after launch, keep the hero server-rendered Liquid and skip video entirely; a video hero is a control surface and a set of playback states bolted to the most visible element on the site.

Related Capabilities

• Campaign landing pages without a page builder — the page the hero opens, and the section stack behind it.
• Video and shoppable media modules — where hero video stops being decoration and starts carrying a product.
• Design system and reusable component library — the token and snippet layer these sections draw their typography and buttons from.
• Collection merchandising and product rails — the cards and rails a hero hands off to.
• Metafield-driven PDP content blocks — the same merchandiser-composable idea on the product page.

Answers to Help You Make Smart Decisions

Can you show a different hero image on desktop and mobile in Shopify? Yes, but not with srcset alone — that changes the size, not the crop. You need two image trees: a <picture> with a media-scoped <source>, or two <img> elements the CSS chooses between. Every hero here does one or the other, and each hand-builds its width ladder so a small asset never gets an upscaled candidate.

Do you need an app for a Shopify homepage slideshow? No, and none of the three storefronts here uses one. Slides are theme-editor blocks with their own settings, so marketing composes the hero where it composes the rest of the page. The trade is that the theme now owns the slide lifecycle, the playback states and the responsive typography an app would have handled.

How do you stop a hero image hurting page speed? By deciding priority from position rather than from a checkbox: the section checks whether it is first in the template order and only then loads eagerly with a high fetch priority. The box is reserved before the image decodes, using an aspect ratio computed in Liquid from the asset that will actually load at that breakpoint — not from the other one.

Should our hero be a video? Only if you can answer three questions. Who maintains the playback states after launch? Does the story work muted, since browsers will not autoplay it otherwise? And is the poster good enough to be the hero on its own, because that is what most visitors see first? If any answer is uncomfortable, a still hero with real art direction beats a video nobody owns.

Ready to Give Your Campaigns a Hero That Works on Both Screens?

Most hero sections are one image stretched two ways and a headline sized for a laptop. Contact us today and we'll tell you whether yours needs an art-directed rebuild, a better poster, or just a second crop.