Images are seen as the classic load-time driver - video is suspected less often, even though a single hero video often weighs more than all the images on a page combined. The share of pages with video is growing: 6.7 percent (HTTP Archive Web Almanac) of mobile pages embed at least one video element, a relative increase of 32 percent (HTTP Archive Web Almanac) over 2022. At the same time, 23 percent (HTTP Archive Web Almanac) of video elements start via autoplay and begin loading immediately - even outside the visible area (web.dev). This article shows how video affects the Largest Contentful Paint, how a poster image with preload speeds up the first visible frame, how preload prevents needless bytes, which codecs and containers make the file smaller, and how facades make the player overhead of embedded videos arise only on click. As a media building block, this belongs in every frontend optimization.
Why Video Is an Underrated Load-Time Driver
A video behaves differently from an image. An image is a single file that is loaded and painted; a video is a container of encoded frame data that the browser loads in chunks, decodes and plays back. As long as a video is not playing, the browser does not need to fetch the entire file - a preview image and a little metadata can be enough. This is exactly where video becomes a load-time driver: letting the browser load the full file immediately, even though the user may never watch it, wastes bandwidth on the critical loading path.
Adoption is rising. The HTTP Archive Web Almanac now counts video on 6.7 percent (HTTP Archive Web Almanac) of mobile and 7.7 percent (HTTP Archive Web Almanac) of desktop pages, a relative increase of 32 percent (HTTP Archive Web Almanac) since 2022. Most clips are short: more than half (HTTP Archive Web Almanac) of videos are under 30 seconds, and nearly a quarter under ten seconds. These are typical hero loops and product animations - often the same role a GIF used to play. And such GIFs are heavy: web.dev notes that animated GIFs are not uncommonly several megabytes (web.dev), even though the same effect can be achieved as video at a fraction of the bytes.
Video Touches Several Core Web Vitals at Once
The Poster Image as an LCP Candidate
For a long time videos did not count as LCP candidates. That has changed: the first painted frame of a video is now a candidate for the Largest Contentful Paint (web.dev). With a hero video, the LCP therefore hangs on exactly that large video at the top. But since the first frame only appears after loading and decoding, the LCP would be tied to the slow video - unless a poster image steps in. The poster attribute shows a static image while the video loads (MDN), and because it loads faster than the video, that image usually becomes the actual LCP element. A poster thus works like a placeholder, similar to progressive image loading with LQIP.
The effect is measurable. On a demo page, DebugBear shows how adding a poster image lowered LCP from 1.55 to 1.23 seconds (DebugBear); preloading the poster at high priority then brought it further to 1.2 seconds (DebugBear). Important: Chrome does not support preloading the video file itself - only the poster image can be preloaded (DebugBear). The poster is therefore treated like a normal image: delivered as a modern format and prioritized with fetchpriority. How exactly this priority hint works is explored in the article on fetchpriority and priority hints; the format choice for the poster itself is covered by our image optimization.
<!-- Preload the poster as a fast LCP image at high priority -->
<link rel="preload" as="image" href="/media/hero-poster.webp"
fetchpriority="high">
<!-- Video with poster; without autoplay, preload=none is enough -->
<video poster="/media/hero-poster.webp" preload="none"
controls playsinline width="1280" height="720">
<source src="/media/hero.webm" type="video/webm">
<source src="/media/hero.mp4" type="video/mp4">
</video>The Core in One Sentence
Only Preload the Poster If the Video Really Is the LCP Element
Control preload: none, metadata, auto
The preload attribute tells the browser how much of the video to fetch in advance. preload=none means no video data is preloaded; preload=metadata fetches only metadata such as the duration; preload=auto allows the whole file to be downloaded even if the user may never play it (MDN). The default is not uniform - the spec advises metadata, but browsers handle it differently (MDN). The attribute is rarely used anyway: only 16 percent (HTTP Archive Web Almanac) of video elements set preload at all, six percentage points fewer than in 2022.
In practice, preload=metadata is tricky: in many browsers it already fetches a chunk of the video via the Content-Range header, so more data flows than intended (web.dev). For a video that does not autoplay, preload=none combined with a poster image is usually the leanest choice - the browser fetches no video bytes until the user clicks play. Note the order of precedence: autoplay takes precedence over preload - if autoplay is set, the browser loads the video regardless of what preload says (MDN).
| preload value | What the browser loads | When it makes sense | Effect |
|---|---|---|---|
| none | No video data, only the poster | Video without autoplay, click to play | Leanest start |
| metadata | Only metadata, often already a chunk | When duration/dimensions are needed early | May load more than expected |
| auto | Potentially the whole file | Only with very high play probability | Expensive on the loading path |
| autoplay | Loads at once, precedence over preload | Short, muted hero loops | Bytes at once, poster as fallback |
Autoplay Videos and Their Cost
Autoplay is popular: 23 percent (HTTP Archive Web Almanac) of video elements start automatically, three percentage points more than in 2022. The cost is rarely visible but real. An autoplay video begins loading as soon as the page is parsed - even when it sits outside the visible area (web.dev). It therefore competes for bandwidth at exactly the moment the browser should be building the first visible frame. A hero video that autoplays loads its bytes in parallel with the rest of the page and can slow the LCP path, even though the user has not consciously noticed the video yet.
If a video is meant to run as an endless loop - the classic GIF role - it needs the attributes autoplay, muted, loop and playsinline together (web.dev): muted so the browser allows it to start at all, and playsinline so it does not jump to full screen on mobile. It is important to cap the load: loading=lazy defers loading the poster and video until the element scrolls near the viewport (MDN). A background loop in the lower third of the page then does not compete at the first byte. The same thinking in loading priorities sits behind lazy loading and code splitting.
Autoplay is not a free effect. Every automatically starting video loads its bytes at exactly the moment the page should focus its attention on the first visible frame. The question is not whether a video autoplays, but whether it does so within the visible area and at a capped weight.
Modern Codecs and Containers: Smaller Files
The biggest lever on video weight is the format. web.dev shows with a concrete example how large the difference is: the same animation weighs 3.7 MB as a GIF, only 551 KB as MP4 (H.264), and just 341 KB as WebM (VP9) (web.dev) - the WebM is thus around 91 percent (web.dev) smaller than the original GIF. The container (MP4, WebM) and the codec inside it (H.264, VP9, AV1) together determine the file size. AV1 typically compresses even more strongly than VP9 (web.dev), but requires a fallback because of device support.
In practice a single format dominates so far: 68 percent (HTTP Archive Web Almanac) of delivered video files are MP4, while WebM reaches only 1 percent (HTTP Archive Web Almanac). The reason often lies in the markup: 42.5 percent (HTTP Archive Web Almanac) of video elements have no source child at all, and another 48.9 percent (HTTP Archive Web Almanac) have only a single one - so the more modern fallback is missing almost everywhere. Yet a simple ordering of several source elements is enough: the browser picks the first format it can play (web.dev). Listing AV1 or WebM first and appending MP4 as a safe fallback delivers the smaller file to modern browsers without locking out older ones. The same format-before-fallback logic applies to images, as our article on WebP and AVIF shows.
<!-- Order = priority: smallest format first, then fallback -->
<video poster="/media/loop-poster.webp" autoplay muted loop
playsinline preload="none" width="960" height="540">
<source src="/media/loop.av1.mp4"
type="video/mp4; codecs=av01.0.05M.08">
<source src="/media/loop.webm" type="video/webm">
<source src="/media/loop.mp4" type="video/mp4">
</video>Choose the container deliberately
MP4 is the safe base, WebM often smaller. Several source elements deliver the smallest playable format and keep MP4 as a fallback - without leaving older devices empty-handed.
Stagger the codec by support
AV1 compresses more strongly than VP9, VP9 more strongly than H.264. The most efficient format comes first, the broadly supported H.264 last - so every browser gets the smallest file for it.
Poster as a modern image
The poster is a normal image and belongs delivered as WebP or AVIF. Small, fast and given fixed dimensions, it carries the first impression before the first video frame is ready.
Adaptive Resolutions: the Right Video per Device
A single large MP4 forces every device to load the same file - the smartphone on a mobile network just as much as the desktop on fiber. Adaptive streaming solves this by splitting the video into short segments at several resolutions, so the browser picks the fitting level depending on available bandwidth. This approach shows up clearly in the field data: around 27 percent (HTTP Archive Web Almanac) of delivered video content already comes via adaptive formats - visible in segment files without a classic extension as well as in the .ts and .m4s segments of adaptive streaming.
Not Every Video Needs Adaptive Streaming
Facades for Embedded Players
An embedded video player from an external service brings its own JavaScript - and that is expensive. According to web.dev data, such a player embed blocks the main thread for more than 1.7 seconds (web.dev) at the median, before a single frame plays. The answer is the facade pattern: instead of the full player, the page first shows only a light, static preview image with a play button that resembles the real player. Only the click loads the actual embed. That way the player-script overhead arises exactly when the user actually requests it - and not on every page load.
The saving is considerable. According to web.dev data, deferring the load of a video embed saves around 500 kilobytes (web.dev) on the initial loading path, and pages with a facade pattern show an average 800 milliseconds (web.dev) faster LCP than pages that load the embed directly. Since many videos are only started by a fraction of visitors, the facade shifts the load from the norm to the exception. The same principle is used by trimming third-party scripts for chat widgets and maps.
Static preview image
The facade shows the video's thumbnail plus a play button. It looks like the real player but loads no third-party JavaScript - just an image and a little CSS.
Preconnect on hover
When the user touches the facade with the mouse, a connection to the video service is opened in advance. That lowers latency on the actual click without loading data beforehand.
Swap on click
Only the click loads the full player and replaces the facade. The user gets the complete functionality - but only when they actually request it.
Overhead Only on Demand
The Implementation Path in Practice
Video performance is not a single trick but a chain of decisions: the right first frame, the lean loading stance, the smallest format and the decoupled embed. The reliable path begins with measurement - which element determines LCP, how heavy each video is, how much script each player brings. From this diagnosis comes a prioritized plan that pulls the biggest levers first.
- First measure which element determines LCP - poster, video frame or another image
- Give hero videos a poster, deliver it as WebP or AVIF and preload it with fetchpriority
- preload=none plus poster for videos without autoplay - no video bytes before the click
- Autoplay loops muted, with playsinline and a capped weight, deferred outside the viewport via loading=lazy
- List several source elements: AV1 or WebM first, MP4 as a safe fallback
- Stream long videos adaptively, encode short loops in two to three fixed resolutions
- Load embedded players as a facade - the player-script overhead arises only on click
- Set fixed dimensions so no layout shift worsens CLS
We implement exactly this chain in frontend optimization - from diagnosing the LCP element through poster, preload and codec to the facade for players. How media load shows up in concrete systems is explored in the articles on Shopware performance and on common brakes in WordPress. And which video actually weighs the most on your pages is shown by a structured performance analysis, before a single line is changed.
Sources and Studies