Hero Sections That Do Not Waste the Fold

A client sent us a hero they’d signed off internally: full-bleed 100vh background video, 3.4MB MP4, headline centred in the dead middle, and a “Learn More” button that scrolled down 900px. Largest Contentful Paint on a throttled Moto G, measured in Lighthouse, was north of 4 seconds. Scroll-depth data from their analytics showed 41% of mobile visitors never reached the second section. The first screen was doing all the work, and it was saying nothing.

That’s the whole problem with hero sections. They’re the most expensive real estate on the site, they get designed first and reviewed by the most people, and they’re usually the slowest and least informative part of the page. The fold is still real in 2026, not as a hard line but as an attention budget, and most heroes blow it on decoration.

Here’s how we build them now, after enough post-launch audits to know which decisions actually move numbers.

What “the fold” actually means now

The fold is not a pixel height. It’s the set of things a visitor can see before making a decision to scroll, and that set varies wildly: roughly 360 to 430 CSS pixels wide on phones with 600 to 790 pixels of usable height after browser chrome, versus 1280 to 1920 wide and 700 to 950 tall on laptops. There is no single safe height.

What’s stable is the behaviour. People scroll immediately and almost reflexively, then stop when nothing earns further attention. The fold’s real job isn’t to contain your pitch. It’s to make scrolling feel worthwhile and to give the small minority who are already sold a way to act right now.

That reframes the design question. Instead of “what do we fit above the fold”, ask “what does the first screen need to prove so the second screen gets read”. Usually three things: what this is, who it’s for, and why it’s credible. That fits in a headline, a subhead and one piece of evidence.

Hero section design: one job, five elements, hard stop

Our working limit for a landing page hero is five elements: headline, subhead of 15 to 25 words, primary CTA, one trust signal, one visual. Every additional element we’ve added past that in A/B tests has either done nothing or made things worse. The worst offender is consistently the second CTA at equal visual weight.

If you need a secondary action, make it a text link or a ghost button at clearly lower contrast. Two primary buttons side by side is a decision tax, and it reads as a team that couldn’t agree.

The headline is a positioning problem, not a copy problem

“Transform your workflow” tells a visitor nothing. The test we use: could a competitor paste your headline onto their own homepage without it becoming false? If yes, rewrite it. Specific nouns beat verbs of aspiration. “Invoice reconciliation for Shopify agencies, done in minutes” is worse writing and a much better headline.

Put the headline in HTML as an h1. Not baked into the hero image, not injected by JavaScript after hydration. We’ve inherited React builds where the entire first viewport rendered client side, so the LCP element was a spinner and the crawler saw an empty shell. Getting the tags right is cheap and pays off in both accessibility and indexing.

Your hero is your Core Web Vitals score

LCP’s “good” threshold is 2.5 seconds at the 75th percentile of field data. In practice the LCP element on a marketing page is the hero image or the hero headline, so the hero essentially is the metric. Treat it that way.

The non-negotiables, in order of how often we find them broken:

• Never lazy load the hero image. loading="lazy" on an above the fold image delays discovery until layout. We still find this in theme demos and in image components that apply lazy loading globally.
• Set fetchpriority="high". Supported across Chromium, Safari 17+ and Firefox. It moves the image ahead of scripts and non-critical CSS in the fetch queue.
• Don’t put the LCP image in CSS. A background-image can’t be discovered by the preload scanner, so it waits for the stylesheet to parse. If you need the image as a background for cropping reasons, use an <img> with object-fit: cover inside the hero, or preload the exact resolved URL.
• Reserve the space. Width, height and aspect-ratio on the image. Hero CLS is almost always either an unsized image or a web font swapping in at a different metric.

<section class="hero">
  <picture>
    <source
      type="image/avif"
      srcset="/img/hero-800.avif 800w, /img/hero-1280.avif 1280w, /img/hero-1920.avif 1920w"
      sizes="(max-width: 767px) 100vw, 55vw">
    <img
      src="/img/hero-1280.webp"
      srcset="/img/hero-800.webp 800w, /img/hero-1280.webp 1280w, /img/hero-1920.webp 1920w"
      sizes="(max-width: 767px) 100vw, 55vw"
      width="1280" height="860"
      fetchpriority="high"
      decoding="sync"
      alt="Reconciliation dashboard showing 142 matched invoices">
  </picture>

  <div class="hero__copy">
    <h1>Invoice reconciliation for Shopify agencies</h1>
    <p class="lead">Match payouts to invoices automatically. Setup takes about ten minutes
      and works with QuickBooks and Xero.</p>
    <a class="btn btn-lg" href="/trial">Start free 14 day trial</a>
    <p class="hero__proof">Used by 2,400 finance teams. No card required.</p>
  </div>
</section>

Note the sizes value. If your hero image occupies 55% of the viewport on desktop, telling the browser 100vw makes it download an image nearly twice the pixels it needs. We’ve cut hero payloads by half on client sites by fixing sizes alone, with no visual change whatsoever.

Fonts deserve their own mention because the hero headline is where font loading failures become visible. A headline that reflows 400ms after paint is both a CLS hit and a cheap-feeling first impression. Our approach is covered in detail in font loading strategy, but the short version for heroes: preload exactly one weight, use font-display: swap with a metric-matched fallback via size-adjust, and never let the hero depend on a font that arrives from an third-party domain.

Height, cropping and the scroll cue

height: 100vh has been broken on mobile for years. Safari and Chrome on Android measure vh against the largest possible viewport, so with the address bar visible your 100vh hero is taller than the screen and your CTA sits below the cut. The fix shipped a while back and is now safe to use: svh (small viewport, chrome visible), lvh (large), and dvh (dynamic, resizes as chrome hides).

Use svh for heroes. dvh causes the hero to resize mid-scroll on iOS, which looks like a bug.

.hero {
  / 100vh is the fallback for anything pre-2023 /
  min-height: 100vh;
  min-height: 100svh;

  / But cap it: a 1000px tall hero on a desktop monitor is wasted space /
  max-height: 760px;

  display: grid;
  align-content: center;
  padding-block: clamp(3rem, 8vh, 6rem);
}

/ Short landscape viewports: let content dictate height instead /
@media (max-height: 600px) {
  .hero { min-height: auto; }
}

Honestly, full-height heroes are usually the wrong default. A hero occupying 70% to 85% of the viewport with the top edge of the next section peeking in performs better in every scroll-depth comparison we’ve run. The partial reveal does the work that scroll-down arrows pretend to do, with no JavaScript, no animation and no explanation. Chevrons bouncing at the bottom of a hero are an admission that the layout failed to imply continuation.

On cropping: decide your focal point per breakpoint rather than trusting object-position: center. Product shots and faces get destroyed by centre cropping on a 390px viewport. Either art-direct with <picture> and separate mobile crops, or set object-position per media query. Canvas ships a lot of its 200-plus demos with separate mobile hero crops for exactly this reason, and it’s worth stealing the pattern whether or not you use the template itself.

Background video and animation: the honest cost

We still build video heroes. They work for hospitality, events, physical products and anything where atmosphere is the actual value proposition. They’re wrong for SaaS, B2B services and anything where the visitor is scanning for a fact.

If you ship one, the rules are strict:

• The poster image is the LCP element. Optimise it as if the video doesn’t exist, because for the first second it doesn’t.
• No audio track at all. Strip it. It saves bytes and removes any chance of autoplay blocking.
• Target 1.5MB for a 6 to 10 second loop. Two-pass H.264 at around 1280 pixels wide, or AV1 if you’re comfortable with the encode time. If it won’t fit, your loop is too long or too detailed.
• Load it after first paint, and never on reduced motion or metered connections.

// Attach the source only once the page is interactive and motion is welcome.
const hero = document.querySelector('#hero-video');
const reduced = matchMedia('(prefers-reduced-motion: reduce)').matches;
const saveData = navigator.connection?.saveData === true;
const slow = /2g/.test(navigator.connection?.effectiveType ?? '');

if (hero && !reduced && !saveData && !slow) {
  requestIdleCallback?.(() => {
    hero.src = hero.dataset.src;   // data-src keeps it out of the preload scanner
    hero.load();
    hero.play().catch(() => {});   // autoplay can still be refused; poster stays
  });
}

This is plain progressive enhancement: the poster and the copy are the real hero, the video is garnish that may never arrive. The same logic applies to WebGL and canvas particle fields, except those also burn CPU continuously and drain batteries. We’ve removed more of those than we’ve built.

Four hero patterns that keep failing

The rotating carousel

Still the most requested, still the weakest. Attention concentrates almost entirely on the first slide, autorotation fights the reader’s own pace, and you now owe keyboard controls, pause-on-focus and ARIA live region handling to be accessible. If three stakeholders each want their message in the hero, the carousel isn’t a solution, it’s a deferred argument. Pick one message and give the others their own sections.

The abstract illustration

Floating gradient blobs and isometric characters holding oversized pencils tell the visitor nothing about the product. A real screenshot with real data, even slightly cropped, outperforms generic art consistently. If the UI is ugly, fix the UI.

The modal that interrupts the hero

A cookie banner covering 30% of the screen plus a newsletter popup at 2 seconds means your carefully tuned first viewport is mostly a cookie banner. If you must have both, delay the popup until 50% scroll depth or an exit signal.

The hero that explains the category

“Email marketing is essential for modern brands.” The visitor already knows, they clicked an ad about it. Start at the differentiator, not the premise.

Measuring whether it worked

Three signals, in priority order.

1. Scroll past the hero. Fire an event when the top of section two enters the viewport. If fewer than 60% of mobile visitors reach it, the hero is a wall and copy is the likely culprit.
2. Primary CTA click rate split by scroll position. If the hero CTA converts at a third of the rate of the identical CTA in the mid-page section, the hero is asking too early. Soften it: swap “Buy now” for “See how it works”.
3. Field LCP, not lab LCP. Lighthouse on your MacBook is a smoke test. Use the Chrome UX Report or real-user monitoring and watch the 75th percentile. A 1.8 second lab score sitting on a 3.6 second field score usually means slow TTFB or a render-blocking third-party tag, not the image.

One caution on testing: hero A/B tests need more traffic than most sites have. Below roughly 1,000 conversions per variant you’re reading noise. If you’re under that, fix the measurable technical problems, write a sharper headline, and spend the rest of your effort on the structure of the full page instead. The hero rarely converts anyone on its own. It just decides whether the rest of the page gets a chance.