Product Video and Core Web Vitals: Autoplay, Codecs, and LCP Impact
Product video — autoplay loops, hero video backgrounds, 360-spin views — frequently destroys LCP and INP on ecommerce pages. The 7-point video audit covering codec choice (AV1, HEVC, H.264), poster preload strategy, autoplay rules, and bandwidth gating.
Product video adoption has accelerated dramatically in ecommerce over the past three years. Shopify's 2024-2025 reports showed that > 60% of top-1000 stores include autoplay video on at least one template (hero, product page, or category banner), and that share continues to grow as platforms standardize video upload tooling.
The performance cost is rarely measured. Video competes with images for LCP attention, blocks INP via decode work on lower-end devices, and adds 1-5 MB of payload that's invisible in standard Lighthouse runs (since Lighthouse doesn't always download autoplay video on test runs). Stores frequently see product page CWV scores drop 15-25 points after adding hero video — without any obvious cause in the Lighthouse waterfall.
This is the 7-point audit for product video that doesn't tank Core Web Vitals.
1. Decide if video should be the LCP element at all
If the hero video autoplays on page load, it competes with the hero image for LCP. Browsers don't always treat the video frame as the LCP candidate — sometimes the first painted poster image is the LCP, sometimes a frame from the video, sometimes a heading that paints before either.
Best practice for ecommerce: don't make video the LCP element. Use a static hero image as LCP, then transition to autoplay video after the image has painted (or after a user gesture). This preserves clean LCP measurement and avoids the 500-2000ms LCP penalty that video decode introduces.
The pattern:
<picture>
<!-- LCP image, preloaded -->
<source srcset="..." type="image/avif" />
<img src="hero-poster.jpg" fetchpriority="high" />
</picture>
<video poster="hero-poster.jpg"
autoplay muted loop playsinline
preload="metadata"
style="display: none"
onloadeddata="this.style.display='block'; this.previousElementSibling.style.display='none'">
<source src="hero.av1.webm" type="video/webm; codecs=av01.0.05M.08" />
<source src="hero.h264.mp4" type="video/mp4" />
</video>
This pattern shows the image immediately (clean LCP), then swaps to video once it's ready. Users see the image first, then the video starts playing — the same UX result as autoplay video, without the LCP cost.
2. Codec strategy: AV1 first, H.264 fallback
For 2026, the codec hierarchy for ecommerce autoplay video:
- AV1 — best compression (50-70% smaller than H.264 at equivalent quality). Browser support: Chrome 90+, Edge 90+, Firefox 100+, Safari 17+ (95%+ global support in 2026). Encoding is slower but a one-time cost
- HEVC (H.265) — Apple ecosystem primary. Good compression. Browser support is fragmented (Safari native, some Chrome with hardware decode); royalty/licensing complications
- H.264 (AVC) — universal fallback. Worst compression but works everywhere
- VP9 — was useful 2015-2022; now superseded by AV1 with the same browser support but worse compression
Provide AV1 with H.264 fallback via multiple <source> elements:
<video autoplay muted loop playsinline preload="metadata">
<source src="product-spin.av1.webm" type="video/webm; codecs=av01.0.05M.08" />
<source src="product-spin.h264.mp4" type="video/mp4" />
</video>
Browsers select the first supported format. AV1-capable browsers (the majority in 2026) get the smaller file; older browsers fall back to H.264.
For 1080p product video at typical ecommerce quality settings, AV1 cuts file size from 2-3 MB to 600-900 KB — a 60-70% bandwidth reduction with no visual quality loss.
3. Resolution: 720p, not 1080p or 4K
Most ecommerce video displays at 600-900 CSS pixels wide. Encoding at 1080p (1920px) or 4K (3840px) wastes bandwidth without visual benefit on the actual display size. The right resolution for ecommerce:
- Hero video on landing pages: 1280×720 (720p), 1.5-3.0 Mbps bitrate
- Product detail video: 1280×720 (720p), 1.5-2.5 Mbps
- 360-spin product video: 640×640 (square, low motion), 800 Kbps-1.5 Mbps
- Background hero video (decorative): 960×540, 600-1200 Kbps
Encoding higher resolutions only makes sense for full-screen lightbox or modal video where the display size approaches the encoded size.
4. Poster image: must be optimized as carefully as any LCP image
The poster attribute on <video> elements determines what shows before the video plays. If the video element is in the viewport, the poster IS the visible content until the first video frame paints — typically 300-1500ms after load on mobile.
Poster optimization:
- Same dimensions as encoded video (or larger for higher-DPI displays)
- Modern format: AVIF or WebP with JPEG fallback (use the
<picture>-as-poster pattern via display swap, or accept JPEG poster as fallback) - Compressed: quality 75-85, typical poster size 30-80 KB
- Preloaded if the video is in the initial viewport
5. preload attribute strategy
The video preload attribute controls how aggressively the browser fetches video data:
preload="none"— fetch nothing until play() is called. Cheapest, but autoplay videos have to fetch from scratch when triggeredpreload="metadata"— fetch the first few KB to read duration/dimensions. Cheap. Good default for ecommerce videopreload="auto"— fetch the entire video on page load. Expensive. Use only for hero videos that must autoplay immediately
For most ecommerce product video — gallery items, secondary content, "watch product in action" buttons — preload="metadata" is the right choice. It avoids loading the full video for users who never scroll to it, while ensuring the video is ready when triggered.
For autoplay hero video that must play immediately on page load, preload="auto" is acceptable, but combine with the LCP-image-first pattern to avoid LCP penalties.
6. Autoplay rules and policies
Modern browsers block autoplay video that has sound. Autoplay rules:
- Video must have
mutedattribute, OR have no audio track at all - Video must have
playsinlineattribute on iOS (otherwise opens fullscreen player) - Video must be small enough that the browser doesn't classify it as "media-heavy"
- User can override autoplay in browser settings — design for the case where autoplay fails
For best autoplay reliability:
<video autoplay muted loop playsinline preload="metadata">
Encode the video without an audio track (saves bandwidth and avoids audio-codec compatibility issues). Most ecommerce product video is purely visual anyway.
7. Bandwidth gating for slow connections
For users on slow networks (Save-Data header, 2G/3G connections, or low data quotas), autoplay video is a bad UX — it consumes a substantial fraction of their data budget for marginal benefit.
Detect slow connections and gate video accordingly:
// Network Information API
const connection = navigator.connection;
const isSlowConnection = connection &&
(connection.saveData ||
['slow-2g', '2g', '3g'].includes(connection.effectiveType));
if (isSlowConnection) {
// Show static image instead; don't load video
document.querySelector('video').remove();
}
Server-side equivalent: read Save-Data request header and respond with HTML that doesn't include autoplay video for clients sending it.
This pattern protects mobile users from incurring data charges on heavy video and protects the store's CWV from being dragged down by slow-connection users' poor LCP times.
The Hidden INP Cost of Video
Video decode happens on the main thread for software decoders, off the main thread for hardware decoders. On low-end Android devices, video decode can block the main thread enough to add 100-300ms to Interaction to Next Paint (INP) measurements.
Mitigations:
- Use codecs with hardware decode support on target devices (H.264 has broadest hardware support; AV1 hardware decode is rolling out in 2024-2026)
- Limit autoplay videos to one per page — multiple simultaneous decodes are catastrophic
- Pause off-screen video via IntersectionObserver — videos scrolled out of view should not continue decoding
The Product Video Performance Checklist
- Video is not the LCP element (use a static poster image for LCP)
- AV1 primary codec, H.264 fallback via multiple
<source>tags - Resolution matches display size (720p for typical product video, not 1080p)
- Bitrate appropriate for compression target (1.5-3 Mbps for AV1, 4-7 Mbps for H.264)
- Poster image optimized like any LCP image — modern format, correct size, compressed
preload="metadata"for most product video;preload="auto"only for heromuted,playsinline, and eitherautoplayor click-to-play- No audio track (encode without to save bandwidth)
- One autoplay video per page maximum
- IntersectionObserver pauses off-screen video to free main thread
- Save-Data and slow-connection users get static image instead
- Total video weight under 1 MB for hero, under 500 KB for product gallery items
- LCP measured before and after video changes — no regression accepted
- INP measured on low-end Android — video decode shouldn't degrade interactions
Product video is a powerful merchandising tool that consistently improves conversion when implemented well — and consistently destroys performance when not. The audit pattern above keeps the conversion benefit while controlling the LCP, INP, and bandwidth costs. StoreVitals scans detect autoplay video on page templates, measure its weight relative to total page payload, identify when video is competing for LCP attention, and flag codec choice and preload-attribute misconfigurations that commonly tank Core Web Vitals scores.