Why video slows stores down — and why it doesn’t have to

“We tried video and the site got slow” is a common sentence and it is usually true. It is also usually caused by one of five specific things, each with a specific fix.

1. Everything loads at once

The default. Ten video elements on a page all start fetching as the page parses, competing with the images and scripts the shopper actually needs now.

Fix: load video as it approaches the viewport. The largest single win available.

2. The video became the LCP element

A large video in the viewport takes over as the biggest thing on the page, so your headline speed metric becomes a measure of video load time.

Fix: keep video out of that slot, or show a poster image immediately so the paint happens on an image rather than on a video file.

3. Source files far larger than needed

A 4K master uploaded because it was what came off the camera, served into a 400-pixel card.

Fix: proper processing on upload, and several sizes so the right one can be chosen per device. Failing that, upload something sensible in the first place.

4. Third-party embeds

An embedded player from another platform brings its own JavaScript, its own tracking, its own fonts and its own connections. The video is often a small part of what actually loads.

Fix: host the video with your store rather than embedding a platform’s player into a commercial page.

5. It is not the video

Worth checking before rebuilding anything. Stores that add video often add it at the same time as a redesign, a new review widget and three tracking scripts. The video is the most visible change and gets the blame.

Fix: record a performance trace and look at the waterfall. If the slow entries are analytics and a chat widget, the video is not your problem.

How to tell which one it is

Open the network panel, throttle to a slow connection, and reload the page without scrolling. The waterfall answers most of this on its own.

• Video files appear before you scroll → cause one. Nothing below the fold should be fetched yet.
• The LCP marker lands on a video card → cause two. Move the section, or make sure a poster paints first.
• A single video file is several megabytes → cause three. The source is being served closer to its original size than it should be.
• Requests to domains you do not recognise → cause four. An embedded player is bringing its own payload.
• The slow entries are analytics, chat and a review widget → cause five. It is not the video.

Throttling is not optional here. On a fast connection every one of these problems is invisible to you and fully visible to a shopper on a train.

The general principle

Every one of these is about scheduling rather than size. Video is large; that is unavoidable. What is avoidable is asking for it before the shopper needs it, letting it block things they do need, or making the page wait on it to look finished.

A page can carry a lot of video and be fast. It just cannot carry a lot of video that was all requested at once.