Because video is usually the heaviest thing on the page, and the browser often starts downloading it before anything else has finished. A single unoptimised hero clip can outweigh every image, font, and script combined. Nothing else on the page changed. The video simply took all the bandwidth first.
We get called in for this a lot. A marketing team adds a looping background video to the hero, the page looks great on the designer laptop, and mobile users on a normal connection stare at a blank box for four seconds. The fix is rarely removing the video. It is almost always changing how it loads.
Video on the web is more common than most people assume. The HTTP Archive Web Almanac found in its 2024 Media chapter that 6.7% of mobile pages and 7.7% of desktop pages include a video element, a 32% relative increase over 2022. More sites are shipping video, and most of them are shipping it badly.
Three things. File size, because video is orders of magnitude larger than an image. Network priority, because a video the browser thinks it needs will compete with your critical content. And decode cost, because playing video uses CPU and battery on the visitor device, not just bandwidth.
File size is the obvious one. A short 1080p clip exported at master quality out of a video editor can run to tens of megabytes. The same clip compressed properly for the web is a fraction of that, with no visible difference at hero size. Most of the video weight we find on client sites is pure export laziness rather than anything the design needed.
Priority is the sneakier problem. If the browser decides your video matters, it will fetch it alongside your CSS and fonts. Those are the resources that decide when the page becomes usable. A video that steals bandwidth from a font file delays every word on the page, and the visitor blames the whole site rather than the clip.
Decode cost matters on older phones. A looping background video keeps the decoder busy the entire time someone is on the page. On a mid range Android device that shows up as a warm phone and a scroll that stutters. We treat any always-playing video as a real cost, not a free decoration.
Yes. Video elements are LCP candidates. According to the Chrome team documentation on LCP, the measurement uses "the poster image load time or first frame presentation time for videos, whichever is earlier". So a hero video is very often the element your LCP score is actually measuring.
That makes the thresholds directly relevant. LCP is considered good at "2.5 seconds or less" and poor above 4.0 seconds, measured at the 75th percentile of page loads. If your hero video takes three seconds to show its first frame, your LCP is three seconds, and no amount of image work elsewhere will save the score.
This is also why the poster image is a performance tool rather than a cosmetic one. Because LCP takes whichever comes first, a small, well compressed poster can complete the LCP measurement long before the video itself is ready. You get a fast score and a page that looks finished. We explain the wider mechanics in our guide to what Largest Contentful Paint is and how you fix it.
Self-host short, silent, decorative clips. Use a streaming service for anything long, anything with sound, or anything a visitor will actually sit and watch. The dividing line is roughly whether the file is small enough to serve as a single download without adaptive bitrate.
Self-hosting a five second looping background clip is fine and often better. You control the compression, you avoid a third-party script, and the file goes out over your own CDN. Adding a full video platform for a decorative loop means loading someone else iframe and player code to show two megabytes of moving texture.
Long-form video is the opposite case. A three minute product demo needs adaptive bitrate so viewers on poor connections get a lower quality stream instead of a stall. Building that yourself is real engineering work. Services like Mux, Cloudflare Stream, Vimeo, and YouTube exist because it is genuinely hard, and their players handle formats and device quirks you should not be maintaining.
The compromise we use most often is a facade. Show a static poster image with a play button, and only load the third-party player when someone clicks. The page stays light for every visitor who never presses play, which on most marketing sites is the large majority, and the people who do press play wait a moment longer. That tradeoff is almost always worth it.
Use preload="none" for anything below the fold, and preload="metadata" as a default. MDN describes metadata as fetching "only video metadata (e.g., length)", while auto means "the whole video file can be downloaded, even if the user is not expected to use it". Auto is almost never what you want.
The specification itself leans conservative. MDN notes that "the default value is different for each browser" and that "the spec advises it to be set to metadata". Browsers disagree, so setting the attribute explicitly is the only way to know what you are getting.
Real sites are not doing this. The Web Almanac 2024 Media chapter found the preload attribute on only 16% of video elements, down six points from 2022. Most videos on the web are loading with whatever default the browser picked, which is a coin flip on how much bandwidth gets spent before anyone presses play.
One caveat worth knowing. MDN is explicit that "the autoplay attribute has precedence over preload". If you set autoplay, the browser has to download enough to play regardless of what preload says. The two attributes are not independent, and people are frequently surprised by this.
Yes, on every video, without exception. A poster gives the browser something to paint immediately, prevents a blank rectangle, and as covered above it can complete your LCP measurement early. MDN describes it as "a URL for an image to be shown while the video is downloading".
Without one, MDN notes that "nothing is displayed until the first frame is available". A blank box where a hero should be is the single worst first impression a page can make, and it is entirely avoidable with a small image file.
Almost nobody does it. The Web Almanac 2024 Media chapter found the poster attribute on just 3% of video elements. That is one of the widest gaps we know of between a trivially cheap best practice and actual adoption, which also makes it one of the easiest wins on a site audit.
Export the poster from the video first frame so there is no visible jump when playback starts. Compress it as WebP or AVIF and size it to the display dimensions, not the source resolution. The same rules that govern every other image on the page apply here.
Only if it is short, silent, and decorative. Autoplay with sound does not work anyway. MDN states plainly that "modern browsers block audio (or videos with an unmuted audio track) from autoplaying". So an autoplaying hero must be muted, which means it cannot carry any information a visitor needs.
That constraint is clarifying. If the video is muted and decorative, ask whether it earns its weight. Sometimes it genuinely does and the motion makes a page feel alive. Often it is a stock clip of a city at dusk that adds two megabytes and communicates nothing. We have removed a lot of those and nobody has ever asked for one back.
Autoplay is popular regardless. The Web Almanac 2024 Media chapter found autoplay on 23% of video elements, up three points from 2022. It is worth remembering that every one of those is silent by browser policy, whatever the designer intended.
If you do autoplay, always pair it with muted, playsinline, and loop, and keep it under about six seconds. MDN also warns of a common trap: autoplay="false" does not disable autoplay, because "the video will autoplay if the attribute is there in the video tag at all". You have to remove the attribute entirely.
MP4 with H.264 remains the safe default for self-hosted clips, and WebM is worth adding as a smaller alternative source. The Web Almanac 2024 Media chapter found MP4 accounts for 68% of video files served, with WebM at just 1%, so compatibility expectations are built around MP4.
You can offer both. The video element accepts multiple source elements, and browsers pick the first one they support. Putting WebM first and MP4 second gives modern browsers the smaller file and everyone else the compatible one.
Beyond format, the settings matter more than the codec. Drop the resolution to what you actually display. A hero that renders at 1400 pixels wide does not need a 4K source. Strip the audio track entirely from muted decorative clips, because you are shipping bytes for something no one can hear. Cap the bitrate and encode with ffmpeg or your editor web preset rather than exporting at master quality.
Also keep it short. The Web Almanac found the median video on the web runs about 30 seconds or less, with nine out of ten videos under two minutes. Long background loops are not a norm you need to match.
Use loading="lazy" on the video element where supported, and use the facade pattern for embedded players. Lazy loading defers the work until the element is near the viewport, so a testimonial video at the bottom of a long page costs nothing to a visitor who never scrolls there.
MDN documents the behaviour clearly. With loading="lazy", videos "will only apply the preload behavior once the video is near or within the viewport", the poster resource downloads only at that point, and an autoplaying video "will not start downloading and autoplaying until the element is near or within the viewport". That is exactly the behaviour you want for anything below the fold.
For third-party embeds the attribute does not help, because the cost is in the iframe and its scripts. That is where the facade earns its keep. Render your own poster and play button, then swap in the real embed on click. The saving is not marginal. You are deferring an entire player runtime, not a single file.
The same discipline applies to images, and the reasoning overlaps almost completely. We covered where it helps and where it backfires in our article on what lazy loading is and when it hurts your website.
Decide the byte cost before anyone exports anything. Agree a ceiling for the hero clip, usually under two megabytes, and hold to it. Then add a poster, set preload deliberately, mute and shorten anything that autoplays, and defer everything below the fold.
Write the ceiling down somewhere the team can see it, because video weight creeps back in on every content update. A number in a shared document survives staff changes in a way that a good intention does not. This is the same reason we set limits on total page weight rather than fixing pages one at a time, which we wrote about in our guide to what a performance budget is and how you enforce one.
If you have a video-heavy site that has quietly got slower and you are not sure which clip is doing the damage, we are happy to take a look. Send us the URL at phoenix.studio and we will tell you what we would compress, defer, or cut.
Tell us where you want to go. We'll tell you how we'd get you there.