Hero Video Only Earns Its Keep When the Poster Carries LCP

Put a video background on the homepage only when the poster image can carry Largest Contentful Paint, mobile gets a still (or click-to-play), and the loop stays muted, short, and compressed. If any of those fail, the video is usually hurting trust and conversions more than it is helping the brand. Film energy on the web is often stills plus disciplined motion — not a 20MB autoplay file. This spoke sits under Websites That Feel Like Films. For the wider performance tradeoff, read Lighthouse Without Killing Design.

The short answer

• Poster image first: the visible still should be the LCP candidate, not the video decode.
• Default mobile to a still or click-to-play. Autoplay background video is a desktop privilege you earn.
• Autoplay in the browser effectively requires muted (and usually playsinline). Sound-on autoplay is a non-starter.
• Honor prefers-reduced-motion: reduce with a static hero — no debate, and no silent fetch of the MP4.
• If the loop exists to “feel premium,” try a graded still plus GSAP or CSS motion before you pay the video tax.

When does a homepage hero video earn its keep?

Use this as a hard gate before you encode anything. Cinema on a marketing site is a composition problem first and a codec problem second. The fold still has one job — listen, tour, merch, contact — and the media has to serve that job without delaying it.

Condition	Go	No-go
Poster is a real optimized image that paints fast	Required	“Video will be the LCP” as the plan
Mobile strategy is still or tap-to-play	Required	Same autoplay file as desktop
File is a short muted loop, compressed hard	Required	Full music video as background
Reduced-motion users get a still	Required	Motion with no escape
Brand moment needs footage you cannot imply with a still	Valid reason	“Competitors use video”
You measured field LCP after adding it	Required before keeping it	Lab green on Wi-Fi desktop only

If you cannot check every Required row, ship the still. A graded frame that arrives on time beats a soft loop that arrives late. That is the same cinema standard as the pillar, without taxing every visit.

What does LCP measure on a video hero?

Largest Contentful Paint is the time from navigation start until the largest image, text block, or video in the viewport is painted. The published “good” target is 2.5 seconds or less at the 75th percentile, split across mobile and desktop. Web Vitals keeps LCP, INP (≤ 200ms), and CLS (≤ 0.1) as the stable Core Web Vitals set.

For <video>, web.dev is specific: LCP uses the poster image load time or the first-frame presentation time — whichever is earlier. That is the whole argument for a poster-first hero. A still can win the race. A first frame waiting on an MP4 usually cannot.

Metric	What it measures	“Good” target (p75)
LCP	Loading — when main content likely appeared	≤ 2.5 seconds
INP	Responsiveness to taps, clicks, keys	≤ 200 milliseconds
CLS	Unexpected layout movement	≤ 0.1

Google evaluates these at the 75th percentile of real-user field data, typically across a rolling ~28-day window in CrUX and Search Console. Lab Lighthouse scores are useful for debugging. They are not the compliance score.

Hero video threatens LCP when the browser treats a late video frame as the largest element, or when a massive download delays the poster. It threatens INP when main-thread work and third-party players jank the first tap. It threatens CLS when the video or player UI resizes the hero after paint. Reserve width and height — or an aspect-ratio box — so the fold does not jump.

Optimize LCP tells you to look at real users first. Lab tools explain why. They do not get to overrule CrUX when the two disagree.

Why must the poster carry LCP?

Because the largest thing in the first viewport is almost always the hero media, and a video file is a worse LCP resource than a compressed still. Video performance on web.dev treats the poster attribute as an LCP candidate and tells you to raise that image’s priority with a preload plus fetchpriority="high". The video itself should not be the thing the browser is waiting on.

If LCP is the <video> element waiting on the network, you lost the plot. The still should win the race.

Practical pattern that usually wins:

1. Hero region is an image (<img> or a sized poster on the video) with a properly cropped, compressed still — AVIF or WebP when your pipeline supports them.
2. Video sits on top or underneath only after the poster is ready. Many implementations keep the poster visible until canplay or first frame, then crossfade.
3. Preload the poster, not a giant MP4. fetchpriority="high" belongs on the LCP image candidate.
4. Give the media box explicit dimensions to protect CLS.
5. Confirm in field tools (CrUX, RUM, Search Console) which element is LCP on mobile after launch — not only in your laptop DevTools.

LCP request discovery is a three-line brief: make the LCP image discoverable from the HTML, put fetchpriority="high" on it or its preload, and do not lazy-load it. A CMS that stamps loading="lazy" on every image will punish the fold. Override it.

How do you keep the poster as the LCP candidate?

Put the still in the first HTML. Do not hide it behind a player runtime. Do not discover it in a CSS file after a blocking stylesheet. Do not inject it after hydration.

<link rel="preload" as="image" href="/media/hero-poster.avif" fetchpriority="high" />

<section class="hero" style="aspect-ratio: 16 / 9">
  <img
    class="hero-poster"
    src="/media/hero-poster.avif"
    alt="Band on stage under red sidelight"
    width="1920"
    height="1080"
    fetchpriority="high"
  />
</section>

Fetch Priority explains why the hint matters: in-viewport images often start at Low priority until layout proves they are visible. That delay is how a “correct” hero still loses 2.5s. An explicit high fetch priority lets the poster start earlier. Do not stamp fetchpriority="high" on three images. Chrome’s own guidance: more than one or two high-priority images makes the hint useless.

Lazy-loading video is equally blunt on the fold. A poster on an LCP video should be preloaded with fetchpriority="high". Videos that are LCP elements should not use loading="lazy" — the same rule as LCP images. preload="none" or preload="metadata" on the <video> keeps the file from competing with the still. preload="auto" on a background hero is how you accidentally spend the user’s bandwidth before they see your name.

Fold pattern	LCP outcome	Use it?
<img> in HTML, sized, AVIF/WebP, fetchpriority="high"	Best default	Yes
<video poster> plus poster preload, video preload="none"	Workable on desktop	When the loop is earned
CSS background-image with a high-priority preload	Workable	When art direction requires a background
Image or video injected by JS after hydration	Late discovery	No
Autoplay film as the LCP candidate, no poster	Decode + bytes tax	No
Third-party player chrome in the first viewport	Extra JS + iframe LCP gaps	No

Optimize LCP splits the metric into four subparts: TTFB, resource load delay, resource load duration, and element render delay. A poster missing from the HTML inflates resource load delay. A 4K JPEG poster inflates resource load duration. A headline hidden at opacity: 0 until a timeline runs inflates element render delay. Fix the subpart you actually own.

• Poster lives in the initial HTML or a <link rel="preload"> in the head
• fetchpriority="high" is on the poster or its preload — not on three decorative images
• No loading="lazy" on the fold still
• Video uses preload="none" or metadata-only until a desktop gate says go
• DevTools “LCP element” on a throttled phone is the poster, not the <video>

Should mobile autoplay a background video?

No. Default mobile to a still. Phones are where musician and brand traffic often converts — follow, tour, merch, contact. They are also where autoplay background video hurts most: data caps, thermal throttling, smaller CPUs, and impatient thumbs.

Basic video on web.dev is explicit: to autoplay on mobile browsers you need muted as well as playsinline. That is permission to play, not a reason to. Permission is not a brief.

Viewport	Hero media	Interaction
Mobile (default)	High-quality still matching the film grade	Optional “Play” for a short clip or music video embed below
Tablet	Still, or light loop only if field LCP stays good	Prefer tap-to-play for anything with sound
Desktop	Muted loop allowed if budgets pass	Never sound-on autoplay

“But it looks so good on my phone on Wi-Fi” is not a field test. Check mid-tier Android on LTE. If the loop stutters or the fold arrives late, cut video on mobile without apology.

Gate the fetch, not only the CSS display. A hidden <video src="..."> can still start a download. Attach the src (or inject the node) only after all three are true: desktop width, no prefers-reduced-motion: reduce, and the poster has painted.

const allowLoop =
  window.matchMedia("(min-width: 768px)").matches &&
  !window.matchMedia("(prefers-reduced-motion: reduce)").matches;

If allowLoop is false, the MP4 never exists in the document. That is the mobile rule. A tap-to-play module below the fold is a different job and a different budget.

What do browsers actually allow for autoplay?

Muted, inline, and usually only after you ask politely. Sound-on autoplay is the thing people still try to ship from a Figma file. Browsers have been blocking it for years.

Chrome’s autoplay policy is blunt: muted autoplay is always allowed. Autoplay with sound needs a user gesture, a high Media Engagement Index on desktop, or an installed PWA / home-screen site. MDN’s autoplay guide says the same thing in implementation language: if you need autoplay, mute it or strip the audio track. If autoplay is disallowed entirely, show the poster and wait for a tap.

WebKit’s iOS video policies are why playsinline is not optional decoration. On iPhone, a <video> without playsinline still wants fullscreen. Muted (or no audio track) is what allows autoplay without a gesture. Unmute without a gesture and playback pauses.

The HTML spec defines playsinline as a hint that the video ought to stay in the element’s playback area instead of jumping to a fullscreen window. Treat it as required on any hero loop.

Approach	Use when	Avoid when
Muted autoplay loop (muted loop playsinline)	Atmosphere, desktop, poster-first	Storytelling that needs audio
Click-to-play	Music videos, interviews, trailers	You wanted wallpaper and got a player UI instead
No video	Most service homes and many artist homes	You are forcing footage to justify a shoot

Autoplay is not required for a premium site. It is optional seasoning. If the brief is “fans should hear the single,” that is a tap, not a background attribute.

Chrome on Android will also pause an autoplaying muted video when it leaves the viewport — documented in the Chrome 58 media updates. Do not rely on that as your only teardown. Pause and detach src when the hero leaves view so a background tab is not decoding a loop for a fan who already scrolled to tour dates.

How do you honor prefers-reduced-motion on a hero?

If the user asks for less motion, give them the poster and stop. No slow fade loop. No “subtle” Ken Burns on a huge file. No delayed video injection that still moves the frame.

prefers-reduced-motion exists because autoplaying video is one of the things that makes a page overwhelming. The query has two values: no-preference and reduce. MDN maps reduce to the OS setting — macOS Reduce Motion, Android Remove animations, Windows Show animations turned off. Animation and motion on web.dev is the implementation note: check the OS setting and give those users exclusive control. Decorative motion comes off. A play button is how they opt in.

Browsers will not do this for <video autoplay> on their own. A CSS animation can be killed with a media query. A media element will keep fetching and playing unless you stop it in CSS and in JavaScript.

@media (prefers-reduced-motion: reduce) {
  .hero-video { display: none; }
  .hero-poster { display: block; }
}

That CSS is necessary and not sufficient. Also:

1. Read matchMedia('(prefers-reduced-motion: reduce)') before you set src.
2. If it matches, never create the <video> node.
3. If a loop is already playing and the user toggles the OS setting, pause, remove src, and show the poster.
4. Do not “respect” the query with a slower loop. reduce means minimize non-essential movement, preferably to none.

Motion on the fold	no-preference	reduce
Desktop muted loop	Allowed if LCP holds	Poster only, no fetch
CSS Ken Burns / slow scale	Small, compositor-only, CLS-safe	Off
Type / CTA entrance	Opacity + translate after LCP	Instant final state
Click-to-play film	Available below the fold	Available, user-started

Reduced motion is not a performance hack you sprinkle on to green a Lighthouse audit. It is the same craft standard as the rest of the site. The poster is the designed cut, not a fallback you forgot to art-direct.

Does a looping hero fail WCAG 2.2.2?

A loop that starts on its own, runs more than five seconds, and sits next to a headline and a CTA is in scope. WCAG 2.2 Success Criterion 2.2.2 Pause, Stop, Hide (Level A) requires a mechanism to pause, stop, or hide moving content in that situation, unless the movement is essential to the activity. “It looks more like a music video” is not essential.

Loop design	2.2.2 reading	What to ship
Still only	Out of scope	Default, especially on mobile
Autoplay ≤ 5 seconds, then freeze	Exempt from this criterion	Rarely worth the encode
Infinite muted loop, no pause control	Fail	Add a real pause, or do not autoplay
Infinite loop with a visible, keyboard-operable pause	Can pass 2.2.2	Still honor reduced-motion with a still
Click-to-play module	Out of scope (user started it)	Correct home for the actual film

A hover-only pause does not count. The control has to be discoverable with a keyboard and usable before the five-second line. The cleaner studio default is: no autoplay on mobile, pause control on any desktop loop you keep, and a still for prefers-reduced-motion. That stack satisfies 2.2.2 without turning the fold into a player chrome farm.

WCAG 2.2.2 is also not a license to flash. Three flashes per second is a different criterion (2.3.1). Grade the footage. Do not strobe the hero.

How large can the loop file be?

There is no single universal megabyte law published as a Core Web Vital. There is physics: every megabyte competes with your LCP image, fonts, and hydration. Video performance exists because containers and codecs change how much bandwidth you burn before the first frame. Compress the texture. Do not ship the master.

Budgets I use as starting discipline for background loops (adjust per project; measure field LCP after):

Asset	Starting budget	Notes
Poster image	Often well under a few hundred KB in a modern format at hero dimensions	This is the LCP candidate
Mobile	0 KB video by default	Still only
Desktop loop	Low single-digit MB after compression, short duration, limited resolution	If you need 15MB+, you are shipping a film, not a texture
Multiple sources	One well-encoded file beats three huge fallbacks	Extra sources multiply waste if mis-preloaded
Audio track on a background loop	0 KB	Strip it. Mute is not the same as omitted

Encode for the crop you show. A vertical phone crop does not need a 4K landscape master — and mobile should not download a loop anyway. Keep atmosphere loops short; under ~5–8 seconds is the range I start from when the job is texture, not narrative. Put the moov atom at the front of an MP4 (-movflags +faststart in FFmpeg) so the browser can read metadata without scanning the tail of the file. That is container hygiene, not a magic LCP number.

If the file only works at cinema bitrate, it does not belong in the hero. Host the film on YouTube, Vimeo, or Mux with a poster and a play button. The homepage job is the still. The watch job is a choice.

• Strip audio from background files
• Match resolution to the desktop crop, not the camera original
• Prefer one source you measured over a stack you never profiled
• Never preload="auto" the loop
• Re-encode when the crop changes. A new artboard is a new file.

When do stills plus disciplined motion beat video?

Most of the time. Video is the wrong tool when the brand moment is color, type, and composition — not footage. It is the wrong tool when you need crisp product or press photography. It is the wrong tool when tour, follow, or merch CTAs must win in the first viewport. It is the wrong tool when you cannot afford the encoding and QA pass every release cycle.

Stills plus motion patterns that still feel like a release campaign:

• Graded hero photograph with a slow opacity or scale within CLS-safe limits
• GSAP-timed type and CTA entrance after LCP
• Short hover or scrub previews on desktop work grids — not the LCP element
• Click-to-play music video module below the fold

Keep motion on transform and opacity so work stays on the compositor. Animating top, left, width, height, or a scroll-tied filter: blur() is how a “subtle” scene melts a mid-range Android. That tradeoff is covered in Lighthouse Without Killing Design. This post is only the go / no-go for the hero file.

Brief	Better media	Why
Identity / atmosphere	Graded still, or short muted desktop loop	Texture, not a runtime
Watch the video	Click-to-play with chapter art	User chose the bytes
Listen now	DSP smart link or embed	A 1080p loop is not a play button
Tour dates	Live dates module	Video should not bury the next show
Press / product	Photography	Soft footage loses the object

Oliver Malcolm–style film energy can still be a graded frame and disciplined motion. Video is optional. The pillar is Websites That Feel Like Films, not websites that feel like a buffering spinner.

What breaks when the video wins LCP?

The failure mode I see on artist and brand homes is boring and expensive. Someone drops a campaign cut into the hero, ships autoplay loop without a poster strategy, and the first viewport becomes a download. Fans on cellular bounce. The follow button is late. Search Console’s phone LCP slides past 2.5s at p75 and stays there for a 28-day window.

Typical break, in order:

1. No poster, or a 2MB JPEG poster “for quality.”
2. <video src="hero.mp4" autoplay muted loop> in the HTML for every viewport.
3. preload="auto" because a tutorial said it makes playback start faster.
4. A third-party player wrapper in the LCP region “so we can add captions later.”
5. No width / height, so the fold jumps when metadata arrives — CLS on top of LCP.
6. No reduced-motion branch, so the people who asked for stillness get a loop anyway.
7. Desktop-only Lighthouse is green. Field mobile is not.

Symptom	Likely cause	Fix
LCP element is <video>	Poster missing, late, or lazy-loaded	HTML still + high-priority preload
LCP is 3–6s on phone, fine on desktop	Mobile is downloading the loop	Still-only mobile; gate the src
Fold jumps when the hero appears	No reserved aspect box	width/height or aspect-ratio
First tap feels dead	Player JS + tags on the main thread	Native <video> or click-to-play below
Reduced-motion users still see motion	CSS hide without a fetch gate	Never attach src
Fans say the homepage “doesn’t load”	Cellular + autoplay file	Delete the loop; keep the still

I have shipped hundreds of production sites. The ones that keep cinema and still convert treat the poster as the product and the loop as gravy. The ones that regress treat the loop as the identity and then spend a month arguing with CrUX.

Do not invent a win from a studio Wi-Fi filmstrip. If field LCP on phone is the video, you are not shipping atmosphere. You are shipping a wait.

How do you know video is hurting conversions?

Lighthouse red is a hint. Business symptoms matter more. Compare a two-week window with video on desktop-only versus sitewide autoplay. Keep the version that protects the primary action — follow, tour, contact, listen — not the version that wins taste arguments in the studio.

• Mobile bounce or rage-taps up after adding the loop (watch session tools if you have them)
• Field LCP regresses past ~2.5s at p75 on phone in Search Console or CrUX
• Play / CTA clicks fall because the fold is busy or late
• Fans on cellular complain the homepage “doesn’t load”
• Battery or heat complaints on long sessions (more common with always-on loops)
• INP worsens after a player library lands in the hero
• CLS ticks up when the poster and the video disagree on aspect ratio

Optimize LCP also warns that home pages are often cold visits — new users, empty cache, extra redirects. That is exactly the traffic you are spending a campaign film on. A warm-cache laptop run is the wrong jury.

If you need a controlled test, do not A/B a 20MB file against a 20MB file. A/B the still fold against the poster-first desktop loop. Measure p75 LCP, the primary CTA, and mobile bounce. Delete the loser.

What should an artist homepage put in the hero?

Musician homepages often want the video treatment because the campaign film feels like the identity. Fair. Still separate the jobs. The fold is one composition. The film is a scene you choose later.

Job	Better media	What the hero must not do
Identity / atmosphere	Graded still or short muted desktop loop	Delay the name and the CTA
Watch the video	Click-to-play module with chapter art	Autoplay the narrative with sound
Listen now	DSP smart link / embed	Pretend a silent loop is a play button
Tour dates	Live dates module	Bury the next city under a teaser
Presave / release	Still + one action	Loop a 30-second cut that postpones the form

If the homepage job is “next show” or “presave,” a looping teaser that delays those CTAs is working against the release. Put the film where fans choose it. The still can still be the frame from the video — same grade, same crop, none of the decode tax.

For service and studio sites the rule is stricter. A background loop behind “Book a sprint” is almost never information. It is decoration competing with the offer. Websites work I take still uses motion. It uses it after the still has done the selling.

How do you confirm the LCP element after launch?

Guessing is how a poster-first build still ships as a video LCP. Optimize LCP wants field data first: CrUX in Search Console or PageSpeed Insights, then a lab trace to explain the number. The LCP node in DevTools on your laptop is a clue. The LCP node on a mid-tier phone in the field is the verdict.

Tool	What it tells you	What it cannot tell you
Chrome DevTools Performance / Lighthouse	Which node was LCP in this lab run	What CrUX users actually got
PageSpeed Insights	URL-level CrUX when traffic exists, plus a lab filmstrip	A substitute for your own RUM on a new URL
Search Console CWV	Phone vs desktop p75 over ~28 days	The exact DOM node
web-vitals onLCP	The element your visitors painted	A green circle in a slide deck

Procedure I run before I keep a loop:

1. Cold-load the homepage on a throttled phone profile. Note the LCP element name.
2. Confirm it is the poster <img> (or the poster on <video>), not the first decoded frame.
3. Repeat with cache disabled and with the production tag soup enabled.
4. Wait for URL-level CrUX if the page has enough Chrome traffic. Origin-level averages will hide a slow home.
5. If the field LCP node is the video, remove the src gate failure — usually mobile is still downloading, or the poster was lazy-loaded.

Framer, Webflow, and Astro fail this in different ways. Framer often hydrates the hero after a canvas paint, so the LCP image is late-discovered unless you pin a real <img> in the first HTML. Webflow background videos are easy to drop on every breakpoint; turn the mobile video off in the canvas, not with a CSS hide. Astro is the friendliest of the three if the poster is in the .astro template and the loop is a client island that mounts only after the desktop + motion gates pass.

• Lab LCP element is the poster on a throttled phone
• Production tags are in the lab run you trust
• Builder background-video is off below the desktop breakpoint
• No player iframe in the first viewport
• You have a delete plan if phone p75 LCP is still the video after 28 days

Implementation checklist before the file ships

This is the production gate. If a row is unchecked, the loop stays on disk.

Attribute	On a background loop	Why
muted	Required	Chrome and Safari block sound-on autoplay
playsinline	Required	iPhone otherwise wants fullscreen
loop	Allowed for texture	Pair with a pause control past five seconds
autoplay	Desktop only, after gates	Not a mobile default
preload="none"	Default	Poster carries LCP; the file waits
poster	Required if the <video> is visible	LCP candidate when an <img> is not also present
controls	Off for wallpaper	On for click-to-play films
src in first HTML	No	Attach after desktop + motion gates

• Poster exported at the hero crop, compressed, modern format when possible
• Poster in the HTML (or preloaded) with fetchpriority="high"
• Explicit width/height or aspect-ratio on the media box
• Video muted loop playsinline preload="none" — never preload="auto" on a hero loop by default
• Desktop media query or JS gate before fetching the MP4/WebM
• Mobile never downloads the loop on first paint
• prefers-reduced-motion: reduce never fetches or plays video
• Visible, keyboard-operable pause if the desktop loop runs past five seconds
• No third-party player chrome in the LCP region
• Audio track stripped from background files
• Field LCP element confirmed as the poster after release
• Primary CTA remains tappable within the first viewport on a mid-tier phone

Be stingy. The browser will play a muted loop if you let it. That is not the same as the loop earning its keep.

Decision tree you can run this week

1. Write the homepage job in one sentence (listen / tour / contact / merch).
2. Design the fold as a still that already sells that job.
3. Ask: does motion add information footage alone can provide?
4. If no → ship still + light motion system.
5. If yes → poster-first, desktop muted loop, mobile still, reduced-motion still.
6. Encode a short, silent, cropped loop. Gate the src. Add a pause control.
7. Measure field LCP / INP / CLS for 28 days. Be ready to delete the loop.

If you cannot complete step 2, you are not ready for step 5. Video will not invent a fold job you did not design.

FAQ

Is autoplay always required on a homepage hero?

No. Autoplay is optional atmosphere. Many strong artist and brand homepages convert on a still fold with a clear listen or tour action. If you autoplay, keep it muted, inline, and poster-first, and only after a desktop gate.

How large can a hero background video file be?

As small as you can make it while looking intentional. Start in the low single-digit megabytes for desktop background loops and verify field LCP. If you need a large film file, do not use it as an autoplay background. Use click-to-play.

Should mobile get autoplay hero video at all?

Default to no for background autoplay. Offer a still that matches the grade, and put playable video behind an explicit tap when the footage matters. Mobile browsers may allow muted autoplay. That is not a reason to spend a fan’s data on wallpaper.

When should I use click-to-play instead of a background loop?

Use background loops for silent texture on desktop when budgets pass. Use click-to-play for music videos, narratives, interviews, and anything with sound or a longer runtime. If the user came to watch, let them press play.

How does hero video affect Core Web Vitals?

Video mostly risks LCP (late largest element or heavy downloads), INP (main-thread and player jank), and CLS (resizing media). Keep the poster as LCP, reserve space, and confirm p75 field metrics. Published good targets remain LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 per web.dev/vitals.

When is a still stronger than a looping hero video?

When the still already carries brand and CTA, when mobile performance slips, when reduced-motion matters, or when the loop is decorative ego. A sharp frame plus craft motion often beats a soft autoplay wallpaper. If any go / no-go row fails, ship the still.

CTA

Film-grade sites earn motion — they do not tax every fan with a hero download.

Explore /websites or book a sprint at /contact?intent=websites-sprint.