Is autoplay hero video bad for Core Web Vitals

Yes. Autoplay hero video is often bad for Core Web Vitals, and muted does not get you off the hook. Web Vitals scores the page at the 75th percentile, split by phone and desktop: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1. An autoplay loop loses that race when the largest paint waits on a first video frame, when player JavaScript stalls the first tap, or when the hero box jumps after metadata arrives. A poster that paints in HTML, a still on mobile, and a muted desktop loop you actually measured is the only version that survives. Cinema craft still lives in Websites That Feel Like Films. The encode checklist lives in Hero Video Slowing Your Site. This spoke is the metric verdict.

The short answer

• Autoplay is a CWV risk, not a style. The file competes with LCP, the decoder and player compete with INP, and an unsized <video> competes with CLS.
• Muted is Chrome’s autoplay policy, not a vitals grade. Chrome’s autoplay rules allow muted playback. They do not score LCP.
• LCP on <video> is poster-or-first-frame, whichever is earlier. If there is no poster, Chrome can still pick the video once a frame presents.
• Phones decide p75. CrUX is real Chrome users, including LTE. The same MP4 that looks fine on studio Wi-Fi will drag Search Console’s phone row.
• Pass means all three metrics are “good” at p75. One green lab circle does not pass the page.

What thresholds does Chrome actually publish?

Core Web Vitals are field metrics. Chrome documents the bands, the percentile, and the pass rule. Lab Lighthouse can help you debug. It cannot substitute for CrUX.

Defining the Core Web Vitals metrics thresholds (updated May 2025) publishes this table. Web Vitals and Google Search Central use the same “good” numbers.

Metric	Good (p75)	Needs improvement	Poor (p75)	What it scores
LCP	≤ 2.5s (2500 ms)	Between 2.5s and 4s	> 4s (4000 ms)	When the largest viewport image, text, or video paints
INP	≤ 200 ms	Between 200 ms and 500 ms	> 500 ms	Click / tap / key → next paint, across the visit
CLS	≤ 0.1	Between 0.1 and 0.25	> 0.25	Unexpected layout movement

Same thresholds on phone and desktop. Chrome’s writeup is explicit: user expectation does not change with device, even though phones are harder. Measure p75 separately per form factor. A desktop “good” does not wash a mobile “poor.”

The pass rule on the same vitals page: a page passes only if all three Core Web Vitals meet the good target at p75. One red metric fails the set.

Why p75 exists, from that same thresholds article: three of four visits should meet the bar, and a handful of terrible outliers should not own the number. Their worked example is 100 visits. At p95, five ugly samples can move the classification. At p75, you need 25. Autoplay on cellular is not five ugly samples. It is often the middle of the phone distribution.

Signal	What it is	Use it for	Do not use it for
CrUX / Search Console	Field, Chrome users, p75	Pass / fail	Naming the LCP node
RUM (web-vitals)	Your users, your pages	Element + attribution	A substitute for enough CrUX samples
Lighthouse Performance	Lab, simulated device	Debugging a build	The Search Console status
DevTools filmstrip	One navigation you drove	Seeing poster vs first frame	Publishing a score

I do not publish invented Lighthouse scores here. If your filmstrip is green on a laptop and Search Console’s phone LCP is orange, trust Search Console.

• You are reading field p75 (CrUX, Search Console, or RUM), not a single lab run
• Phone and desktop are separate rows
• All three metrics are in the good band before you call the hero “fine”
• You know which URL group owns the homepage (Search Console groups similar URLs)

How does LCP treat poster vs first video frame?

Largest Contentful Paint is blunt on <video>: the candidate timestamp is the poster image load time or the first-frame presentation time, whichever is earlier. That sentence is the whole LCP argument for a poster-first hero.

If the poster is in the HTML, compressed, and discoverable, it can win the race and close LCP before the MP4 has decoded a frame. If there is no poster, or the poster is lazy-loaded, or the still is a 2MB JPEG “for quality,” LCP waits on the video pipeline.

Chrome 116 changed the no-poster case. The Chromium LCP changelog (rolled out around 2023-08-22) made videos eligible LCP candidates even without a poster attribute, timestamped at first full frame presentation. Dropping the poster does not hide you from LCP. It can make LCP later, because the first frame has to present.

Fold setup	What LCP can pick	Typical outcome
HTML <img> still, sized, AVIF/WebP, fetchpriority="high"	The still	Best default
<video poster> plus poster preload, video preload="none"	Poster if it paints first	Workable on desktop after you measure
<video autoplay> with no poster	First presented video frame	LCP waits on download + decode
JS-injected player after hydration	Late-discovered image or iframe poster	Resource-load delay on Optimize LCP
YouTube / Vimeo embed in the first viewport	Often an iframe poster CrUX sees and RUM misses	Extra JS, extra LCP gap

Optimize LCP splits the metric into four subparts. Autoplay heroes usually blow one of them:

1. TTFB — the HTML is slow, so the poster is not even discoverable yet.
2. Resource load delay — the still is not in the first HTML (CSS background, JS inject, loading="lazy").
3. Resource load duration — the poster is huge, or the MP4 is the LCP resource.
4. Element render delay — the hero sits at opacity: 0 until a timeline or canplay fires.

A poster that wins against the first frame still fails if it paints at 3.8s. “Poster is the LCP element” is necessary. It is not sufficient.

web.dev also notes a CrUX vs RUM trap: the Largest Contentful Paint API does not see iframe content, but the metric does. A YouTube poster inside an embed can be the field LCP while your first-party onLCP never names it. If the fold is an iframe, believe CrUX over a RUM snippet that cannot see into the frame.

Fetch Priority is the other half of poster-first. In-viewport images often start at Low priority until layout proves they are visible. An explicit fetchpriority="high" on the still (or its preload) is how the poster starts before the loop, fonts, and tags. Chrome’s guidance: more than one or two high-priority images makes the hint useless.

Priority mistake	What happens to LCP
No poster, autoplay MP4	First-frame presentation time
Poster in CSS background-image only	Preload scanner may miss it; add an HTML preload or use <img>
loading="lazy" on the fold still	Resource load delay on purpose
fetchpriority="high" on five images	Hint stops meaning anything
preload="auto" on the <video>	Loop competes with the still on the same connection
Cross-origin poster without Timing-Allow-Origin	Older browsers expose load time, not render time — still set the header

Procedure when the LCP node is the video:

1. Confirm the LCP element in a throttled-phone DevTools run and in field onLCP if you have RUM.
2. Put a real still in the initial HTML. Do not discover it in a stylesheet after a blocking CSS file.
3. Preload that still. Put fetchpriority="high" on the still or its preload — not on three decorative images.
4. Set the <video> to preload="none" or metadata-only until a desktop gate says the loop may exist.
5. Keep the poster visible until you intentionally crossfade. Do not hide the still to “let the video be LCP.”
6. If the fold is a third-party embed, remove it from the first viewport and re-read CrUX / RUM. Do not debug only the parent-frame observer.

Is muted autoplay a Core Web Vitals pass?

No. Muted autoplay is a permission. Core Web Vitals are a score.

Chrome’s autoplay policy says muted autoplay is generally allowed. Autoplay with sound needs a user gesture, a high Media Engagement Index on desktop, or an installed PWA / home-screen context. MDN’s autoplay guide says the same thing in implementation language: mute it or strip the audio track, or wait for a tap.

That is why so many teams ship <video autoplay muted loop playsinline> and then act surprised when Search Console is still orange. The browser agreed to play. It did not agree that LCP is 2.1s.

Claim you hear in kickoff	What is actually true
“It’s muted, so Core Web Vitals will be fine”	Mute is autoplay policy, not LCP / INP / CLS
“playsinline fixes iPhone”	WebKit’s iOS video policies need playsinline to stay in-page. Still not a vitals pass
“If it autoplays, users see content faster”	Users see a spinner, then a late frame. LCP timestamps that frame
“We’ll add sound on hover”	Hover is not an INP interaction, and unmute without a gesture pauses on iOS
“YouTube autoplay is the same as a native loop”	An iframe player is extra JS, extra LCP surface, and INP inside the iframe still counts in CrUX

Treat mute as table stakes for any desktop loop you keep. Then score the loop like any other hero asset.

• Audio track stripped from background files (mute ≠ omitted)
• playsinline present if a loop exists
• Sound-on playback is tap-to-play, never the fold default
• You still have a field LCP, INP, and CLS read after the muted loop ships

How does an autoplay hero tax INP?

INP measures click, tap, and key interactions from input to next paint, for the whole visit — not the first tap only. Good is ≤ 200ms at p75. Poor is > 500ms. Chrome usage data on that page notes that most of a visit happens after load. A hero that looks painted and then ignores the first CTA tap still fails INP.

Lighthouse does not report INP. Web Vitals says the lab proxy is Total Blocking Time. A green TBT on desktop is not a field INP pass on a mid-range Android.

Autoplay heroes hurt INP in three boring ways:

1. Main-thread work during load. Demux, first-frame setup, canvas/WebGL posters, and “smart” players compete with the click handler on Listen / Tour / Contact.
2. Third-party embeds in the fold. INP includes interactions inside iframes. CrUX will see a YouTube chrome tap that your first-party RUM may miss.
3. Work that continues after paint. An always-on loop plus scroll-tied effects plus tag managers is how a later tap — not the first one — becomes the INP sample.

INP ignores scroll and hover. A Ken Burns CSS scale is not an INP event. The dead tap on the CTA while the main thread is busy is.

INP splits an interaction into three clocks. Autoplay heroes can inflate all three:

INP part	What it is	Autoplay hero pattern
Input delay	Time until handlers start	Long tasks from player setup, font work, tag soup
Processing duration	Handler work	CTA click wired through a player API or a timeline waiting on canplay
Presentation delay	Time to the next paint	Main thread still decoding / compositing the loop

FID is gone as a Core Web Vital. INP replaced it as a stable metric in 2024. Do not report “we pass FID” as a substitute. INP watches the visit, not only the first input.

Hero runtime	INP risk	Prefer
Native <video muted loop playsinline> after poster paint	Medium — decode + your own listeners	Desktop-only, pause offscreen
Builder background-video widget	Medium–high — extra runtime you do not own	Native element or a still
YouTube / Vimeo / Mux player in the first viewport	High — iframe JS + INP inside the frame	Click-to-play below the fold
GSAP / Framer timeline hiding the CTA until canplay	High — first tap waits on media	CTA visible with the poster
Heavy timeupdate / canvas posterizers	High — handlers on every frame	Compositor-only motion, or no loop

web.dev is also explicit: a page can report no INP if nobody clicked, tapped, or typed. Bots and “open and bounce” sessions do not invent a good INP. Absence of INP in a lab run is not a pass.

Procedure for a suspect hero:

1. In the field, attribute INP to the interaction (RUM or a web-vitals onINP debug build). If the target is the hero CTA or the player, you found it.
2. In the lab, tap the primary CTA during load on a throttled phone. That is when the main thread is busiest.
3. Remove the third-party player from the first viewport. Re-measure.
4. If a native loop stays, pause and detach src when the hero leaves the viewport so a background tab is not still decoding.

How does an autoplay hero cause CLS?

CLS measures unexpected layout movement. Good is ≤ 0.1 at p75. Poor is > 0.25. A hero that reserves no box, then expands when video metadata or player chrome arrives, is a CLS machine sitting on the largest element on the page.

Expected shifts — user-initiated — are not the problem. Autoplay is not user-initiated. The fold jumping because height: auto met an MP4 is unexpected.

CLS scores a shift as impact fraction times distance fraction. A full-viewport hero that moves even a modest distance is an expensive event because the impact fraction is huge. That is why an unsized autoplay box is worse than a small card that nudges.

Session windows matter: Chrome scores CLS in windows, not as one infinite sum for a tab left open overnight. A loop that keeps reflowing on every timeupdate is still a bug. A single metadata-sized jump at start is the usual autoplay case.

Shift source	Why it scores	Fix
<video> with no width / height / aspect-ratio	Box grows when the first frame or poster arrives	Reserve the crop in CSS or HTML
Poster 16:9, video 2.35:1	Swap restyles the fold	One aspect, one encode, one still
Player chrome (controls, captions, big play) appearing on loadedmetadata	Overlay changes layout or the media box	Native loop with no chrome, or tap-to-play later
Web font swap plus a late video	Headline and media both move	size-adjust / optional display, reserved hero
Cookie banner or edit bar pushing the hero	Unrelated, but stacks with media CLS	Account for it; do not blame only the MP4

CLS is not “the video looks smooth.” A silky loop inside a jumping box still fails.

• Hero region has an explicit aspect box before any media request
• Poster and loop share crop and ratio
• No third-party player UI in the LCP region
• Reduced-motion users get the same reserved box, still image, no fetch

Why does mobile data decide your p75?

Because Core Web Vitals are a distribution, not your office Wi-Fi. Defining thresholds chose p75 so three of four visits meet the bar, and so a handful of terrible outliers do not own the number. Cellular visits are not outliers. On many brand and artist homes they are the middle of the distribution.

An autoplay file on mobile does three things field data will notice:

1. Bytes compete with the LCP still. Even with a poster, preload="auto" or a <video src> in the HTML can start the MP4 on the same radio as the poster.
2. CPU and thermal limits stretch INP. Decode plus hydration plus the first tap is a mid-range Android problem, not a MacBook problem.
3. Late paint looks like a broken site. Users bounce. Those sessions still contribute LCP if the largest element eventually paints — or they never interact, so you get a bad LCP and no INP sample to “balance” it.

Basic video on web.dev: mobile autoplay needs muted and usually playsinline. That is permission. It is not a reason to spend the user’s data plan on wallpaper.

The Network Information API (navigator.connection.saveData, downlink, effective type) exists in Chromium. It is not a reliable iOS Safari signal. Do not build the mobile gate on saveData alone. Gate on viewport, prefers-reduced-motion, and “did we attach src at all.”

Visitor	What they should download	What wrecks p75
Phone, any network	Poster still only	Same autoplay MP4 as desktop
Phone, Save-Data / LTE	Still only, no loop fetch	Hidden <video src> that still requests
Tablet	Still, or tap-to-play	Desktop loop “because it fits”
Desktop, prefers-reduced-motion: reduce	Still only, no fetch	CSS-hidden video that still loads
Desktop, no-preference, budgets pass	Optional muted loop	preload="auto" on a campaign master

A hidden video node can still download. Attach src only after: desktop width, no reduced-motion, poster painted. If any gate fails, the MP4 must not exist in the document.

Mobile gate, in order:

1. Read viewport (or a desktop breakpoint you actually ship). If it is a phone, stop.
2. Read prefers-reduced-motion. If it is reduce, stop.
3. Confirm the poster has painted (or at least that the <img> exists in HTML and is not lazy).
4. Then create the <video> or set src. Not before.
5. On pagehide / offscreen, pause and drop src so a background tab is not decoding wallpaper.

Do not invert that order. A CSS display: none after a src in the markup is how phones still pay for the file.

I have shipped hundreds of production sites. The ones that keep a loop keep it as a desktop privilege. The ones that regress treat “it autoplays on my phone on Wi-Fi” as a field test.

How do Search Console and CrUX judge the homepage?

Search Central on Core Web Vitals recommends good vitals for Search and for users, and says this sits with other page-experience aspects that ranking systems seek to reward. That is not a promise that a 2.4s LCP will outrank a competitor. It is also not permission to ignore phone LCP because “ranking is more than vitals.”

Data path:

Tool	Window / source	What it can tell you	What it cannot
CrUX	Real Chrome users, origin and (sometimes) URL	Whether enough users exist to score you	Which DOM node was LCP
Search Console CWV report	CrUX, commonly a rolling ~28-day view	Phone vs desktop status, URL groups	A substitute for RUM on a new URL
PageSpeed Insights	CrUX on top when eligible, Lighthouse below	Field vs lab on one URL	INP from a no-interaction lab run
web-vitals RUM	Your visitors, your pages	Element, attribution, device	A green circle in a slide

No CrUX row means not enough Chrome traffic yet — not that you passed. Lab-only green on a new homepage is a hypothesis.

CrUX publishes origin-level data more often than URL-level data. PageSpeed Insights will say so. If you only have origin CrUX, a blog template can hide a homepage autoplay regression — or a homepage still can hide a slow article chrome. That is why RUM on / matters even when the origin looks “needs improvement” for unrelated reasons.

URL groups in Search Console can lump templates. The homepage is usually its own URL. A campaign film you added to / will show up there, not in a blog group, once CrUX has samples.

Google evaluates good / needs improvement / poor per metric, then the page needs all three in good. Fixing desktop CLS while phone LCP sits above 2.5s at p75 still leaves the phone assessment failing.

Do not wait for a single overnight PSI run after you strip autoplay. Plan on the rolling window. A one-day RUM dip the right way is a good sign. The Search Console status change lags.

• Origin CrUX vs URL CrUX identified (or noted as missing)
• Homepage URL group opened in Search Console, phone tab first
• RUM on / recording LCP element and device class
• Change log dated so you can align a deploy with the 28-day blend

What usually fails first when teams ship autoplay?

LCP. Then CLS. INP shows up when someone drops a player library on the fold, or when the first CTA tap lands during decode.

The failure mode I keep seeing on brand and artist homes is not exotic. A campaign cut becomes the identity. Someone pastes autoplay muted loop into the hero. The poster is an afterthought JPEG, or there is no poster. Mobile gets the same file. Studio Lighthouse on Wi-Fi looks acceptable. Twenty-eight days later the phone LCP row in Search Console is the problem, and nobody wants to kill the film.

Typical break, in order:

1. No poster, or a poster that is larger than the loop deserved.
2. <video src="hero.mp4" autoplay muted loop> in the HTML for every viewport.
3. preload="auto" because a tutorial said playback would start faster.
4. A third-party player wrapper “so we can add captions later.”
5. No reserved aspect box — CLS on top of LCP.
6. No src gate, so reduced-motion and mobile still download.
7. A desktop-only lab audit used as the ship ticket.

Symptom in the field	Likely cause	First fix
LCP element is <video> or a late first frame	Poster missing, lazy, or losing the race	HTML still + high-priority preload
Phone LCP “needs improvement” or poor, desktop good	Mobile is fetching the loop	Still-only mobile; never attach src
CLS ticks when the hero appears	Unsized media or ratio mismatch	Aspect box; one crop
INP ugly on first tap	Player JS or CTA hidden until canplay	Native video or still; CTA with the poster
PSI lab looks fine, Search Console does not	Lab is not p75 field	Believe CrUX; instrument RUM
New URL has no CWV row	Not enough CrUX samples	Use RUM; do not claim a pass

This is the expensive version of cinema: you paid for a shoot, then paid again in bounce and in a month of orange Search Console while the 28-day window digested the MP4.

How does this affect conversion?

A late LCP delays the thing you asked them to do. A high INP ignores the tap when they try. CLS makes them miss the button. I will not invent a conversion percentage or a Lighthouse-to-revenue curve. Measure your own primary action against field p75.

What I will say from shipping work: the fold still has one job. If autoplay postpones the name, the offer, and the CTA so the loop can “feel premium,” you traded the job for texture. Texture does not book a sprint.

If the homepage job is…	Autoplay loop tends to…	Better fold
Book / contact	Hide or delay the form CTA	Still + one action
Listen / follow	Pretend a silent loop is a play button	DSP link; film below
Tour / merch	Bury the next date under a teaser	Dates or product, still grade
Atmosphere / identity	Sometimes earn a desktop muted loop	Poster-first, mobile still

Watch session tools if you have them, but do not wait for a qualitative complaint. Pair:

• Phone p75 LCP vs the day you added the file
• Primary CTA click-through on mobile
• Rage-taps / repeated clicks on the hero button (INP symptom)

If LCP crosses 2.5s at p75 on phone after the loop ships, treat that as a conversion bug even before analytics argues with you. People cannot click a CTA they have not seen.

Search Central’s page-experience language is a ranking alignment, not a conversion study. I will not cite a fake “X% bounce from autoplay” number. Run your own week.

A/B the still fold against a poster-first desktop loop. Do not A/B two giant files. Keep the variant that protects the action.

• Primary CTA named before the test (one action, not four)
• Phone LCP p75 captured for the same dates as the CTA rate
• Mobile autoplay off in both variants unless you are specifically testing it — you should not be
• Stop the test if phone LCP leaves the good band; that is not a “brand win”

What should you ask a designer about this?

Ask production questions, not taste questions. The still is the title card. The loop is optional seasoning. If the designer cannot answer these in writing, do not encode.

Question	Acceptable answer	Walk-away answer
What is the LCP element on purpose?	Named still, crop, format	“The video is the hero”
What does mobile get?	Matching still, no loop fetch	“Same file, it’ll be fine”
What is the crop and ratio?	One ratio for poster and loop	Poster 16:9, letterboxed film
Does the loop carry story or texture?	Texture, short, muted	Full music video as wallpaper
Where does sound live?	Tap-to-play module later	Sound-on autoplay
What is the reduced-motion cut?	Art-directed still, no fetch	“They’ll still see a slow fade”
Who owns the encode after crop changes?	Named person, new file per crop	“We’ll just scale the master”

Put those answers in the brief before Framer, Webflow, or a custom hero. Performance is an art-direction constraint, not a post-launch apology.

Checklist to send with the first still:

• Poster frame is graded and cropped at the hero aspect
• Mobile never requires the moving file to “feel like the brand”
• CTA contrast holds on the still, not only on a later video frame
• No player chrome in the composition
• A pause control exists if a desktop loop runs more than five seconds (WCAG 2.2.2) — implementation detail in the hero video spoke

When is a custom site worth it for this?

When the builder makes the wrong default easy and the right gate expensive. Autoplay widgets in Framer vs Webflow vs Custom are a stack choice, not a vibe.

Stack	Where autoplay CWV usually breaks	When custom is worth it
Framer	Background video on every breakpoint; extra runtime; harder src gating	You need a hard mobile still, preload control, and a loop that must not exist in the document on phones
Webflow	Background video + CMS-hosted masters; lazy-load stamped on the fold still	You need HTML-first LCP and a fetch gate the Designer panel will not give you
Custom (Astro and friends)	You can still mess it up — but the gate is yours	Unusual motion, strict p75, or a player you refuse to put in the fold

Custom is not automatically faster. A custom page that hydrates a React player into the hero will lose to a Webflow still. Custom is worth it when you must:

1. Put the LCP still in the first HTML with fetchpriority="high".
2. Attach video src only after desktop + motion gates.
3. Keep third-party players off the first viewport.
4. Own the encode pipeline (poster AVIF/WebP, loop with faststart, audio stripped).

Decision script for this week:

1. Can the builder put an <img> in the first HTML with fetchpriority="high" and no lazy-load? If no, you are already fighting LCP.
2. Can you prevent the MP4 from existing on a 390px viewport? If no, autoplay is a CWV bug waiting for CrUX.
3. Can you keep YouTube / Vimeo out of the first viewport? If no, INP and iframe LCP are in play.
4. If you answered no twice, custom (or a hard component override) is cheaper than another month of orange phone LCP.

If the site is a campaign landing that dies in six weeks and the still already passes phone LCP, do not rebuild the stack to add a loop. If the homepage is a years-long brand asset and the builder’s video component keeps winning LCP in the field, that is a sprint conversation — Websites — not another theme toggle.

How do you prove the autoplay hero is the CWV problem?

Guessing is how a poster-first build still ships as a video LCP. Prove the node, the viewport, and the field window.

1. Field first. PageSpeed Insights or Search Console: is phone LCP, INP, or CLS the failing row?
2. Identify the LCP element. Chrome DevTools Performance / Experience panel on a throttled phone. Then, if you have it, onLCP in RUM — lab and field can disagree.
3. See whether the loop is requested on mobile. Network panel, disable cache, mid-range phone or throttling. If hero.mp4 appears on a 390px viewport, the gate failed.
4. Force a control. Deploy still-only on mobile (or still-only everywhere) and watch RUM the same week. CrUX will lag.
5. Do not celebrate a lab-only INP. Tap the CTA during load. If you cannot reproduce, your RUM attribution is the map.

Evidence	Enough to act?	Not enough
Phone CrUX LCP > 2.5s at p75 after the loop shipped	Yes	Desktop Lighthouse green
RUM says LCP element is <video> on Android	Yes	One teammate’s iPhone on Wi-Fi
Network log shows MP4 on mobile	Yes — kill the fetch	“It’s muted though”
INP attribution is the player iframe	Yes — move it below	TBT on a desktop lab run
CLS traces to the hero box	Yes — reserve the aspect	“The animation is on transform”

Video performance on web.dev is the encode companion: poster as LCP candidate, raise its priority, do not make the video the thing the browser waits on. This post’s job is to make you believe the field number before you argue about bitrate.

• Phone and desktop CrUX (or RUM) captured before the change
• Same after, with dates — 28-day Search Console will blend old sessions
• LCP node recorded, not assumed
• Mobile waterfall saved; MP4 present or absent
• One change at a time (kill mobile fetch before you recut the film)

What should you skip if you only have a week?

Skip a new shoot. Skip a player migration. Skip arguing about desktop bitrate until phones stop downloading the file.

One-week order:

1. Ship a still-only mobile hero. Gate src. Confirm the MP4 is absent on a phone waterfall.
2. Make the poster the LCP candidate in HTML with a high-priority preload. Kill loading="lazy" on that still.
3. Reserve the aspect box. Kill the CLS jump even if the loop stays on desktop.
4. Pull third-party players out of the first viewport.
5. Honor prefers-reduced-motion by never fetching.
6. Watch RUM for a week. Do not wait for Search Console to finish a full 28 days before you decide whether mobile still-only helped.

Do not spend the week:

Temptation	Why it can wait
Re-encoding 4K “one more time”	Mobile should not get the file at all
Adding captions to the background loop	Background loops should not be the film
Sound-on autoplay experiments	Blocked, and irrelevant to LCP
Chasing a lab 100	Chrome does not require 100; field p75 is the bar
Rebuilding the stack in seven days	Still-only mobile is a gate, not a migration

If after that week phone LCP is still over 2.5s at p75 in RUM, the still itself is the problem — too heavy, too late in HTML, or blocked by TTFB and fonts. Fix that before you discuss bringing a loop back.

Week-one checklist:

• Mobile waterfall: zero request for the loop file
• DevTools LCP node on a throttled phone: the still, not <video>
• Hero box does not change height when you disable cache and reload
• Reduced-motion: no video request
• Primary CTA is visible with the poster, not after canplay
• RUM (or at least PSI field panel) saved on day 0 and day 7

FAQ

Is autoplay hero video bad for Core Web Vitals?

Yes, often. Autoplay heroes fail Core Web Vitals when LCP waits on a first video frame instead of a poster, when player JavaScript or decode delays the next paint after a tap (INP), or when an unsized <video> shifts the fold (CLS). Muted autoplay is allowed by Chrome’s policy; it is not a p75 pass. A poster-first still on mobile, with a measured muted desktop loop only after field data holds, is the version that survives.

How do I measure whether an autoplay hero is hurting Core Web Vitals?

Read field p75 for LCP, INP, and CLS on phone and desktop in Search Console, PageSpeed Insights CrUX, or your own web-vitals RUM — not a single laptop Lighthouse run. Confirm the LCP element; if it is the <video> or a late first frame, the hero is in the dock. Check a mobile waterfall for the MP4. Then ship still-only on phones and compare RUM the same week. CrUX’s rolling window will lag.

What usually fails first when teams try this?

Largest Contentful Paint on mobile. Teams ship one autoplay file to every viewport, skip a real poster strategy, and trust a desktop lab run. CLS shows up next when the hero has no aspect box. INP shows up when a YouTube or builder player sits in the fold and the first CTA tap lands during load. Fix the mobile fetch and the poster before you recut the film.

How long does this take to show results?

RUM can move within days of killing the mobile fetch or swapping in a real poster. Search Console and CrUX commonly reflect a rolling ~28-day window, so the official status lags while old sessions drain out. Do not wait a month to take the MP4 off phones if the waterfall already shows the download. Plan communications around the lag so nobody “reverts the fix” because CrUX has not caught up.

What should I skip if I only have a week?

Skip a new shoot, a player rebuild, and bitrate arguments. Spend the week on still-only mobile, an HTML poster with fetchpriority="high", a reserved aspect box, no third-party player in the first viewport, and a reduced-motion fetch gate. Watch RUM. If phone LCP is still over 2.5s at p75 after that, the still and the document are the problem — not the encode preset.

When is this not worth doing yet?

If you have no hero video, do not add one to “fix” brand. If the still already fails phone LCP, adding a loop will not help. If the URL has no CrUX row yet, you still need RUM, but a stack rebuild just to autoplay is not the first move. If the page is a short-lived campaign and the still converts, leave the film below the fold as tap-to-play. Autoplay is optional seasoning. It is not the identity.

CTA

If the fold is trying to be a film and phone Core Web Vitals are paying for it, that is a website sprint — not another autoplay attribute.

Websites · Book a website sprint