Video for the web: weight, speed and the decision that comes first

Does this page need video at all?

Our position: most business pages should not autoplay video, and many of them should not carry video at all.

That comes from an agency that makes and sells video, which is exactly what makes it worth trusting. A page with a background video has pulled megabytes and put the visitor's processor to work decoding frames before they have read a single word. If that video says something the text and the image cannot, the cost is right. If it is atmosphere, it is not.

Three questions, in this order, settle it. First, what does this video show that a still and two sentences do not; if the answer is movement, like a demo or a process, video is correct. Second, does the visitor want it or do we want it; someone who came to see prices does not want the company introduction film. Third, what is lost if it never plays; if the answer is nothing, the video is decoration.

On this site, those three questions took us to a place where the theme does not contain a single video tag and every figure is drawn with HTML and CSS. We sell video, and our own video lives somewhere else, not in the load path of the pages that sell.

Where exactly does video hit page speed?

In two places, and only one of them is the one everybody thinks of.

The first is weight, and it is familiar: the bytes being downloaded compete for the same bandwidth as the rest of the page, and on mobile over an average connection the video wins that competition because it is bigger. The second is less known and matters more: the video itself can be the page's LCP element. The web.dev documentation lists the video element as an LCP candidate, and for it whichever comes first is used: the poster image load time or the first frame presentation time.

Which means that if the biggest thing above the fold is a video, the metric Google measures as page experience is tied to it. The threshold web.dev gives for a good LCP is 2.5 seconds or less, at the 75th percentile of loads, and anything over 4 seconds counts as poor.

The practical consequence is two lines long. If the video does not autoplay, always give it a poster, because then an optimised image sits on the LCP path instead of a video download. And if that poster is the largest element on the page, web.dev suggests raising its priority with fetchpriority="high".

One trap shows up constantly: a poor poster, or a poster that is itself several hundred kilobytes. A poster is an ordinary image and it obeys the same optimisation rules; if you do not compress it, all you have done is move the problem.

Which video tag settings actually matter?

Four of them, and the biggest effect belongs to the one that gets set least often: preload.

The web.dev video chapter says preload="none" outright for playback the user initiates. That single attribute takes the heaviest download on the page out of the load path.

The poster is the second. MDN says that without a poster nothing is displayed until the first frame is available, and then that first frame is shown as the poster; so with no poster you either have an empty rectangle or you are forced to fetch the file earlier.

Autoplay is the third and is more a decision than a setting. web.dev writes that autoplay should only be used when necessary and as the result of an anticipated need for the user. MDN also notes that modern browsers block autoplay for video with an unmuted audio track, so an autoplaying video with sound will in practice not play at all.

And GIF replacement is the fourth, the one place where autoplay is almost always right. If you want a short looping animation, use a silent video with autoplay, muted and loop instead of a GIF. For exactly this case web.dev suggests stripping the audio stream entirely with ffmpeg's -an flag, because removing the audio stream reduces the file size.

One point that does not make the checklists: these four settings do nothing for a badly encoded file. Bring the resolution down to what is actually displayed; sending a 1080-pixel file into a frame that is 360 pixels wide on a phone is not something any of these attributes compensates for.

Where should the file live: your server or a platform?

Both choices are valid and they are for two different situations; what separates them is control against load.

When you serve the file yourself, everything is yours: no one else's player, no extra script, no logo and no suggested next video, and no visitor data going anywhere else. The cost is equally clear: bandwidth and traffic come out of the same server that serves your HTML, and a long video on shared hosting is where this decision breaks.

When you use a platform, they carry the load and you get adaptive streaming and multiple quality renditions for free. In exchange a third origin joins the page with its own script, the look of the player is not yours, and whatever happens inside that player follows that service's rules.

The rule we use is simple: anything shorter than about ten seconds that is decorative or demonstrative goes as our own file with muted autoplay; anything long, that someone sits down to watch, goes to a platform behind a poster image and lazy loading, so the player script only arrives after a click.

And one technical trap that hits both: putting video inside a page that is itself page-cached. The video file does not come from the HTML cache and has its own path, so the speed score a tool gives you may not reflect the video at all. So after every change, open the page once with throttled network in your browser's developer tools and watch what is actually downloaded.

What does a score of 90 mean, and what does it not say?

The Lighthouse performance score runs from 0 to 100, and Chrome's own documentation puts the bands like this: 0 to 49 is poor, 50 to 89 needs improvement, and 90 to 100 is good. The number we target is the lower edge of the green band, which is 90.

Now for what the score does not say, which matters more than the score. Lighthouse is a lab test: one run, on a simulated device, over a simulated network. Your real users are on different phones and different networks, and that shows up in field data, not in this number.

For video the gap is wider than usual, because user behaviour is part of the equation. A page whose video is preload="none" scores beautifully in the lab, because nobody clicks. The real experience of the person who does click is not in that score at all.

So read the score as an alarm, not a target. Under 90, something on the load path needs looking at. Over 90 only means the load path is clean; how long the video takes to start after a click is something you measure separately. If you want to see where all of this sits inside a speed project, site speed optimisation explains the process.