Adding Video to a Website Without Slowing It Down

Self-hosting or a video platform

There are two common ways to put video on a site:

• Embed from a video platform, such as YouTube or Vimeo. The platform stores the file, converts it into versions for different screens and connections, and streams it. You paste in its player. The trade-off is that the player brings the platform's code, and sometimes its branding, suggestions or cookies, onto your page.
• Self-host the file on your server or a storage service and show it with the HTML <video> element. You control the experience completely, but you also handle file formats, sizes and bandwidth yourself. Long videos watched by many people are better served by a streaming service than by a plain file on the web server.

A sensible split for many business sites: short, silent clips such as product loops are self-hosted; longer talking videos, tutorials and testimonials go on a platform and are embedded.

Embeds: load the player only when needed

A standard embed loads the full player as soon as the page loads, whether or not anyone watches. Chrome's Lighthouse documentation on lazy loading third-party resources with facades describes the fix. A facade is a static element that looks like the embedded player but is not functional, so it costs much less to load. The pattern is:

1. on page load, show the facade, typically the video's thumbnail with a play button;
2. on mouseover, start connecting to the video service;
3. on click, replace the facade with the real player.

Lighthouse flags pages that load deferrable embeds such as the YouTube player, and the same documentation notes that chat widgets and social buttons can use the pattern too. For an embed further down the page, the loading="lazy" attribute on the <iframe> at least stops it from loading until the visitor scrolls near it. Our Core Web Vitals guide explains how heavy third-party code affects loading and responsiveness.

Self-hosted video done well

MDN's reference for the <video> element and web.dev's article on lazy loading video cover the attributes that matter:

• poster: an image shown while the video is downloading. Without it, nothing is shown until the first frame is available. A good poster also tells people what the video is about. Optimise it like any other image; see our image optimisation guide.
• preload="none": for video that does not autoplay, web.dev says this is the best way to avoid loading the whole video until needed.
• loading="lazy": where supported, delays both the video and its poster until the element is near the viewport. Browsers that do not support it on media elements ignore it, so keep preload and poster as well.
• width and height: MDN recommends explicit dimensions for all videos to avoid layout shift, and says they are especially important for lazy-loaded ones.
• More than one source: web.dev's examples offer WebM and MP4 versions in separate <source> elements, so each browser picks one it can play.

Animated GIFs are a special case. web.dev's article on replacing GIFs with video notes they can be huge, and that a <video autoplay loop muted playsinline> element reproduces their behaviour, playing automatically, looping, silent and inline, at a fraction of the size.

Autoplay and background video

Browsers limit autoplay. Chrome's autoplay policy always allows muted autoplay, while autoplay with sound is allowed only in certain cases, for example after the user has interacted with the site. MDN notes that modern browsers block video with an unmuted audio track from autoplaying. So any video that starts by itself should be muted, and should not need its sound to make sense.

Background videos in a hero area also have an accessibility rule. WCAG success criterion 2.2.2, Pause, Stop, Hide, says moving content that starts automatically, lasts more than five seconds and is shown alongside other content needs a way for the user to pause, stop or hide it. Add a visible pause button. Before using a large background video at all, weigh it against a still image: web.dev's advice to avoid autoplay where possible leaves the choice with the visitor, and a still image is far lighter.

Captions, transcripts and controls

WCAG success criterion 1.2.2, Captions (Prerecorded), exists so that people who are deaf or hard of hearing can follow video. Captions cover more than dialogue: they identify who is speaking and include meaningful non-speech sounds. The W3C's guide to making audio and video accessible also recommends:

• A transcript, a text version of the speech and non-speech audio, ideally a descriptive transcript that also describes the visual information. The W3C notes descriptive transcripts are required for people who are both deaf and blind.
• Description of visual information (audio description), so people who cannot see the video get the visual information they need. The W3C notes this is easier when it is planned into the script before filming.
• A media player that supports accessibility.

Captions also help everyone watching with the sound off. With self-hosted video, add captions as a WebVTT file in a <track> element; platforms have their own caption upload, and automatic captions should be checked and corrected. Our accessibility basics guide covers the rest of WCAG.

Helping Google find your video

Google's video SEO best practices set out what it needs to show a video in search results:

• the video must be on an indexed page and must not be hidden behind other elements;
• it must have a valid thumbnail at a stable URL, and use a supported file type such as MP4 or WebM;
• for the richer video features, Google suggests a dedicated watch page for each video where it makes sense for your business, meaning a page whose main purpose is to show that one video. A blog post with a supporting video is not a watch page.

Google adds that an indexed watch page does not guarantee the video will be indexed. VideoObject structured data helps Google understand the video. Its required properties are name, thumbnailUrl and uploadDate; recommended ones include description, duration, contentUrl for the file and embedUrl for the player. If you use a facade, check in Search Console that Google still finds the video.

Embeds and privacy

A platform's player can set cookies or similar storage when it loads, which may need consent under UK and EU rules. YouTube offers a privacy-enhanced mode; YouTube's help page says views in this mode are not used to personalise the viewer's YouTube experience or advertising outside your site, and any ads on the video are non-personalised. A facade also helps, because nothing from the platform loads until the visitor presses play. Our cookie consent guide covers how embeds fit into a consent banner.

A checklist

• Long or popular videos are on a platform or streaming service; short silent clips are self-hosted.
• Embeds use a facade, or at least loading="lazy" when below the fold.
• Self-hosted video has a poster, preload="none" unless it autoplays, dimensions and more than one format.
• Animated GIFs are replaced by muted, looping video.
• Anything that autoplays is muted and has a pause button.
• Every video with speech has checked captions, and a transcript where it helps.
• Important videos have their own page and VideoObject structured data.
• Embeds are covered by your cookie banner and privacy policy.

Frequently asked questions

Should I host video myself or use YouTube or Vimeo?

Short, silent clips such as product loops are easy to self-host with the video element. Longer videos are usually better on a platform or streaming service, which converts and streams them; embed them with a facade so the player only loads when someone presses play.

Why does a YouTube embed slow my page?

A standard embed loads the full player code as soon as the page loads, even if nobody watches. Chrome's Lighthouse documentation recommends a facade: a static thumbnail with a play button that is replaced by the real player only when clicked.

Can a background video autoplay?

Only if it is muted: Chrome always allows muted autoplay but restricts autoplay with sound. If it runs for more than five seconds alongside other content, WCAG 2.2.2 requires a way to pause, stop or hide it.

Do website videos need captions?

For accessibility, yes. WCAG success criterion 1.2.2 requires captions for prerecorded video with audio, covering dialogue, who is speaking and meaningful sounds. The W3C also recommends transcripts and description of important visual information.

How do I get my video into Google search results?

Put it on an indexed page where it is not hidden, give it a valid thumbnail at a stable URL and use a supported format. Add VideoObject structured data with at least name, thumbnailUrl and uploadDate, and consider a dedicated watch page for important videos.

Want video on your site that loads fast and works for everyone? See our website development service and all our services, or email info@creahive.com.