Frontend Performance

Video Poster Images and LCP: How to Keep Video Heroes Fast

This guide focuses on the LCP mechanics of Video Performance Optimization, within Image & Media Optimization. When a hero section is built around a video, the largest element in the viewport is the video element — and what the browser paints there first is either the poster image or, if there is none, the first decoded frame. In Chromium, both are eligible LCP candidates: the poster as an image, and the first frame of a video as a video-type candidate. Whichever paints first with the largest area defines LCP until something larger replaces it.

That makes the poster one of the most important images on the page, and one of the most commonly neglected: a full-resolution PNG export of a video frame, referenced only in a poster attribute (which the preload scanner may discover late), downloaded at default priority, sometimes larger than a mobile-sized video rendition. Fix the poster and the video hero's LCP behaves like any well-optimised image hero.

Video hero LCP with three poster setups Timelines comparing LCP for a video hero with no poster, an unoptimised poster, and an optimised preloaded poster. Video hero LCP with three poster setups No poster HTML+CSS video data → first frame PNG poster HTML+CSS 1.4MB PNG poster AVIF preloaded 90KB AVIF poster 0ms 500ms 1000ms 1500ms 2000ms 2500ms 3000ms 3500ms 4000ms 4500ms LCP 2.5s The preloaded AVIF poster starts downloading while the HTML is still arriving and paints well inside the budget.

Rapid Diagnosis

  • Identify the LCP element. In the Performance panel, if LCP points at the <video> element, check the LCP entry's url: a poster URL means the poster won; a video URL or empty means a frame did.
  • Check the poster's size and format. Exported PNG or JPEG frames at full video resolution are common and huge.
  • Check discovery. Is the poster requested early (preload scanner or preload hint) or late (after CSS/JS)?
  • Check priority. Poster requests often start at Low priority.

Root Cause Analysis

1. Missing poster. LCP waits for video bytes and decoding of the first frame, which is far slower than an image.

2. Oversized poster. Full-resolution lossless frames weigh hundreds of kilobytes to megabytes.

3. Late discovery and low priority. Posters set by JavaScript or inside client-rendered components are found late; the poster attribute may not be fetched at high priority.

4. Poster replaced too early. If the video starts playing before the poster finishes, the first frame can become a later, larger LCP candidate.

Poster choices compared Comparison of poster strategies for a video hero by LCP effect. Poster choices compared Poster strategy Discovery Typical LCP effect No poster first frame only LCP waits for video Full-size PNG frame attribute, low priority slow image LCP Responsive AVIF + preload early, high priority image-speed LCP Poster via img overlay srcset/sizes, fetchpriority best control

Step-by-Step Resolution

1. Produce a lightweight poster at display size

bash
ffmpeg -ss 0 -i hero.mp4 -frames:v 1 -vf "scale=1280:-2" hero-poster.png
npx sharp-cli -i hero-poster.png -o hero-poster-1280.avif -f avif -q 50
npx sharp-cli -i hero-poster.png -o hero-poster-640.avif -f avif -q 50 --resize 640
# trade-off: aggressive AVIF compression can introduce banding in smooth
# gradients common in video frames; inspect the poster at full size.

2. Preload the poster with high priority

html
<link rel="preload" as="image" href="/media/hero-poster-1280.avif" fetchpriority="high"
      imagesrcset="/media/hero-poster-640.avif 640w, /media/hero-poster-1280.avif 1280w" imagesizes="100vw">
<video autoplay muted loop playsinline preload="metadata" width="1280" height="720" poster="/media/hero-poster-1280.avif">
  <source src="/media/hero-720.webm" type="video/webm">
  <source src="/media/hero-720.mp4" type="video/mp4">
</video>
<!-- trade-off: the poster attribute has no srcset; the preload's imagesrcset
     picks the best file for the device, but the attribute still names one URL.
     Keep them consistent or use the overlay approach below. -->

Expected outcome: the poster paints early as the LCP element; the video takes over afterwards.

3. Use an image overlay for full responsive control

Render a real <img> with srcset, sizes and fetchpriority="high" absolutely positioned over (or instead of) the video until it starts playing, then fade the image out.

html
<div class="hero-media">
  <img src="/media/hero-poster-1280.avif" srcset="/media/hero-poster-640.avif 640w, /media/hero-poster-1280.avif 1280w"
       sizes="100vw" width="1280" height="720" fetchpriority="high" alt="">
  <video autoplay muted loop playsinline preload="metadata" width="1280" height="720"></video>
</div>
<!-- trade-off: the overlay adds a few lines of JavaScript to remove the image on
     the 'playing' event, and both elements must stay exactly aligned to avoid
     a visible shift. -->

4. Delay video start until after LCP when bandwidth is scarce

On slow connections, attach the video sources after load (or after the poster's load event), so video bytes never compete with the poster.

Fast video hero checklist Four steps that make a video hero's LCP behave like a fast image hero. Fast video hero checklist Poster at display size in AVIF/WebP Tens of kilobytes rather than megabytes Preload with fetchpriority=high Or an img overlay with srcset and sizes preload=metadata on the video Video data never competes with the poster Same aspect ratio and dimensions No shift when playback replaces the poster 1 2 3 4

Verification

In a throttled trace, the LCP marker should land on the poster image within the image-LCP budget, well before video playback starts. The LCP entry's url should be the poster. In RUM with the web-vitals attribution build, the LCP resource URL for hero templates should be the poster and resourceLoadDelay should be small.

Worked Example: An Automotive Landing Page

A car manufacturer's model pages opened with a full-bleed video hero, no poster and preload="auto". LCP on mobile was the first video frame at 4.6s p75. The team generated 640px and 1280px AVIF posters (70KB and 150KB), added an <img> overlay with fetchpriority="high", switched the video to preload="metadata", and started playback after the overlay image loaded. LCP p75 dropped to 1.9s, with the poster as the LCP element on 96% of page views; the video still began playing within a second of LCP on typical connections.

Choosing the Poster Frame

The poster is what most users see first, and what users with autoplay blocked or reduced motion see permanently. Choose it deliberately: a frame that communicates the product or message on its own, with legible composition at mobile sizes, and visually continuous with the video's first frame so the transition is seamless. Avoid frames with text that becomes illegible when compressed, and avoid very dark or very busy frames that compress poorly. A designer's two minutes here often matters more than the codec choice.

Common Mistakes

  • Lazy-loading the poster or the hero video container. Delays the LCP element.
  • Using the same giant poster for mobile and desktop. Wastes bytes on small screens.
  • Mismatched aspect ratios. The poster and video must share dimensions or the swap shifts layout.
  • CSS background posters. Background images are discovered late; use an attribute or <img>.

Edge Cases

Safari behaviour. Safari's handling of first-frame LCP and poster timing differs; test in Safari for visual smoothness even though LCP is reported from Chromium.

Streaming players. HLS/DASH players initialise via JavaScript; posters must not depend on that JavaScript to appear.

Reduced motion. With prefers-reduced-motion, keep only the poster — which is now the permanent hero image.

Low bandwidth. On 2G or with data saver, skip the video entirely and serve the poster as a static hero.

FAQ

Does the poster count as an image for LCP?

Yes. Chromium treats a video's poster as an image LCP candidate, with timing based on when the poster paints. The first video frame can also be a candidate if no poster is set.

Should the poster be preloaded if it is in the HTML?

The poster attribute may not be fetched as early or as high priority as an <img>. A preload with fetchpriority="high" (or an <img> overlay) guarantees early, high-priority loading.

Can the first frame become a later LCP candidate?

If it paints a larger area than the poster, yes. With matching dimensions it is the same size, so it does not replace the poster as LCP.

How small should a poster be?

As small as possible at acceptable quality: typically 50–150KB in AVIF for a full-width mobile-to-desktop hero. Use responsive sizes so phones download the smaller version.

What if the video is a third-party embed?

Use a facade: a thumbnail image (optimised like a poster) with a play button, loading the player on click. The thumbnail becomes the LCP element.

Does fetchpriority on the poster delay CSS?

It raises the image above other images and late scripts, but render-blocking CSS remains high priority. On very constrained connections, keep critical CSS small so both arrive quickly.